Podcasts about JavaScript

Share on
Share on Facebook
Share on Twitter
Share on Reddit
Copy link to clipboard

High-level programming language

  • 1,720PODCASTS
  • 10,019EPISODES
  • 44mAVG DURATION
  • 3DAILY NEW EPISODES
  • Dec 3, 2021LATEST

POPULARITY

20112012201320142015201620172018201920202021


Best podcasts about JavaScript

Show all podcasts related to javascript

Latest podcast episodes about JavaScript

No Plans to Merge
Aeropress and ADHD

No Plans to Merge

Play Episode Listen Later Dec 3, 2021 99:49


We talk about coffee mechanisms, some alpine news, and a big segment on ADHD. Also Daniel is very bullish on those Dapper Ducks.

Changelog Master Feed
JavaScript will kill you in the Apocalypse (JS Party #204)

Changelog Master Feed

Play Episode Listen Later Dec 3, 2021 67:03


Salma Alam-Naylor joins us this week to share her thesis that JavaScript is best in moderation, and is a liability when creating performant, resilient, and accessible web applications. Salma says we're drunk on JavaScript, and it's time we learn how to leverage this powerful web primitive to enhance our web experiences, alongside HTML and CSS, instead of purely relying on JavaScript to completely run the show.

Sixteen:Nine
Niko Sagiadinos, SMILControl

Sixteen:Nine

Play Episode Listen Later Dec 1, 2021 35:06


The 16:9 PODCAST IS SPONSORED BY SCREENFEED – DIGITAL SIGNAGE CONTENT Going back roughly a decade, there were a couple of digital signage vendors talking up and marketing their capabilities for a technology called SMIL. That's short for Synchronized Multimedia Integration Language, but you probably knew that. OK, probably not. It's a bit like HTML, in that it is a programming language developed and supported by the same global entity that developed and continues to support and evolve HTML. If you don't know what HTML is, then this podcast edition is one you may want to pass on. It gets a little nerdy. SMIL, going back 10 years, was being touted as a next big thing for signage, but that didn't happen. However, there are companies using SMIL for managing digital signage networks - particularly companies who have some technical chops in-house and want something that's flexible and in their control. I stumbled recently on a little company in Hannover, Germany that has been squarely focused on SMIL. I had a good, albeit technical, chat with Niko Sagiadinos, one of the two partners in a firm called SmilControl. He walked me through what SMIL is all about, and the advantages he says the technology brings to digital signage. Subscribe to this podcast: iTunes * Google Play * RSS TRANSCRIPT Niko, thank you for joining me. Can you tell me what your company is all about and when it got started?  Niko Sagiadinos: We started in 2011 with a content management system based on SMIL, and I was a developer years before and one day a friend of mine came up with the idea of 101 Signboard and told me that he desperately needs a content management system. So I had at that moment a content management system and I developed two models for this system, one to administer the playlist and one to administer the player, and so it began. I liked SMIL and the open nature of ideas at that time. I often used open source software and that's a concept I personally liked very much and so I stuck with SMIL and I saw that there were a lot of things possible with SMIL, and I liked it and I stayed with it.  So there will be people listening who will already be going, what is he talking about? What is SMIL? Over here, it's sometimes called “smile.” I know it's an acronym for some sort of a language. Can you explain?  Niko Sagiadinos: Yes. SMIL is an acronym for synchronized multimedia integration language. You can also call it the HTML for digital signage or multimedia presentations and SMIL makes it possible to create a multimedia presentation, interaction with time synchronization. That's where the first word synchronized comes from, and just like you can build websites with HTML, you can build presentations or digital signage presentations with SMIL.  So I know that SMIL has been around for several years. I can remember a competitor of yours, SignageLive, talking about SMIL and working with ideas over in Taiwan, on their devices as well. They made a fair amount of noise about it, and then it just dropped off, and Jason and his team moved on to other stuff seemingly. What's the distinction between SMIL and HTML5?  Niko Sagiadinos: SMIL is focused on presentations and the arrangement of media, while HTML is more focused on the arrangement of information and the implementation for the media, but SMIL can synchronize them. So you can position a media to play first, then second, then the third, then repeat, go to one and then continue. These are things which are not natively possible with HTML. You can do it with HTML, but you need to program with JavaScript, and that's easier to do with SMIL. SMIL also has some orders to control how a presentation runs and the presentation is not the thing for HTML. With websites, you can do interactions with the website but you cannot synchronize media sequentially, parallelly, or what happens when a special time comes, for example, at 5 o'clock, a video has to run an, and then another playlist starts. There are a lot more complicated things focused on presentation which are better solved by SMIL. So why has the digital signage industry migrated more to HTML5 and those kinds of web services and JavaScript as opposed to SMIL?  Niko Sagiadinos: Now I have two theories. The first is it is easier for most to make a web design and it seems to be easier to make its own thing. This is one, it seems to be easier to make a website, but it has some disadvantages because it's a browser, you need a digital signage player. You can integrate a browser in a digital signage player, but you also need commands to administer this player and this is with the browser a little bit more complicated.  The second thing is that every company wants to do his own thing. So you need to buy a software from company X and you need to buy a digital signage player software or hardware from company X, and this is what we call a window lock in. Every company wants to lock in their customers to use their product and so they have established this connection between an authoring system and the player system, and with SMIL, this connection can break up so you can use any player from any company or even my open source player, and you can write your own SMIL authoring software, if you like, and that's something companies don't want. They want to have it all together and sell a solution, and that's the reason, in my opinion, they stuck more on this product.  In the early days, they tried to establish SMIL as low-cost signage also, but it was a mistake from my point of view, because SMIL can do much more than what they were focused on. They focused on the media player only and said, okay, this is only low cost signage, but you can run a SMIL software even under a mobile and computer, and this is a way to do more high cost signage for example, and there's another reason. Companies don't want to cannibalize their own product. For example, if you get a market leader and they have their own system, and now you come to SMIL, and they have a feature that has low cost signage, because if they said, okay, they can do the same things like our enterprise product with SMIL, they'll lose money.  So your company is SMIL Control. What do you offer? I know that recently you introduced a free software player as well that works with SMIL.  Niko Sagiadinos: We started in 2012 officially with only a content management system and most of our customers used players from IAdea but some of our customers wanted to create their own player. They were not satisfied with the player from IAdea for various reasons, because there was no company, they wanted to have more control, maybe they got some cheaper devices from Asian manufacturers and so they started to write their own SMIL software and that caused some problems. When three or four of our resellers started to write software, and put a lot of resources to develop this player, but they didn't focus on marketing and to make sales, and just focused on developing and in 2015-16, I decided, okay, we have now some success with our content management system, I tried to develop a player for those who want to create their own hardware. And the only target for me is to create an open source player, and this player is the Garlic Player, and now after five years, increasing companies are showing interest in this player to brand it under their name or to use it in their player and to make their own hardware around this player. That's the goal. To be clear, this is the software that plays out the media and there's a hardware player, which is not what we're talking about here?  Niko Sagiadinos: At SMIL Control, our focus is only on software. You can take our software and use it as you want and this is the same with the  . The Garlic Player is a piece of software that you can use on a Windows PC, on a Linux PC or an Android device. You can even name it on Android as X Player, and you can sell it at X Player by making a service out of this, and that's the goal. You can use our software, and the only consistent way to publish the software is to open source the player software so everybody can take part of it.  I apologize, I'm not overly technical. I'm probably more technical than a lot of people, but I have my limits, sometimes severe.  You were describing how IAdea, a great little company from Taiwan. I'm good friends with them, they had a SMIL based hardware player, and I think you mentioned that there are some other companies that also have SMIL based hardware players, but you're saying, your garlic player doesn't need to be on one of those devices, it could run on a Windows or Linux box, or even on an Android box and I think I read that it doesn't even need to be rooted, right?  Niko Sagiadinos: You can use this on an Android together with a launcher, and the launcher is another software which works together with the player and the launcher does not need the device to be rooted. I know this is a little tech focused discussion, but yes, at the end of the day, there's only software running on hardware. Even with IAdea and the other players, there's just software which is running on the hardware, and the goal is that if someone wants to offer his own hardware, they can use our software.  So if I'm an end-user or a solutions provider, I'm listening to this and getting the explanations around the advantages of SMIL over HTML5 and so on. I'm wondering if they're listening and thinking, “This sounds interesting, but I don't know anything about that particular programming language and how much of a curve do I have to get up,” or is if I'm an end-user, is it invisible and you don't need to know anything about it?  Niko Sagiadinos: This is a valid point. Our products are not for end users. They are for resellers who have a technical background and know what they have to do. For example, there are a lot of companies in Germany who want to offer digital signage products and have tech support, but they don't have knowledge in digital signage and have possibly two opportunities.  The first opportunity is to build everything from scratch by themselves, or to get someone who sells them a complete package, a full service but if you are between that, you will have your own hardware maybe, and you want to use your own hardware, but you don't have the software for it. You have knowledge of hardware and PC, but you don't have the software and you need software. That's our customer.  The end users will be totally overwhelmed because they will run into problems because of the technical nature because you have to know a lot of things, but a company which has a technical background, like a solutions provider for PCs or someone else that has this technical background, and so they can work together.  And would there be a lot that they need to learn or would it be pretty straightforward if they're already working with web technologies? Niko Sagiadinos: They won't have much to learn because the software is from us, and the only thing they have to learn is how to control the software. Of course we can offer bandwidth with this. We can offer that you can take it and use it or maybe you can do more things. If you need your own CMS, and you want to use only the player, we can help you, and the two documentation for SMIL and everything is open so there is no need for NDAs and things like that and we'll make the things to learn much easier, so you can learn, but you can only start to use it and install it.  So you could be trained on it. It's just like any other piece of software, you just might need some training?  Niko Sagiadinos: Exactly. We are computer nerds and we can show them how to use this software,  how they can use these concepts. So if this is for our solutions providers/resellers, that sort of thing, I gather something about what you're saying is this gives them the ability to control it, maybe put their own front-end skin on it so it looks like their product, and as you say, you're the nerds, you guys are just sitting in the background. Niko Sagiadinos: It can be digital signage companies too, or companies who want to be digital signage companies, but they don't want to reinvent the wheel and they get used in other industries.  We are something intermediate. You can take a full service provider, that's okay. But if you don't want this full service provider and you don't want to develop everything by yourself, you can use our products. So we are in the middle.  Do you get pushback from companies who say, this sounds really interesting, but I don't know much about this language. I know I asked this already, but this makes me a little nervous in that it's unfamiliar to me. Why wouldn't I just go with something with one of the established products out there that's using more familiar technology?  Niko Sagiadinos: Yes, of course, we get this feedback, but for me, it's a matter of time. There are customers for this because we get requests and these requests started coming in even a year before I started marketing. The last few years we got some big customers and we didn't even need to get out. So it was a secret. We had no real website and my partner and I know how to get customers and they have commissions for software, and so we started last year to make websites to do marketing. And in this year, the requests began to increase from other companies, and we have started to work with companies in Eastern Europe, for example, who use the Garlic Player and even join the programming and the coding.  To go back to your question, there are companies that say, okay, that's too complicated for us. We want to use some other things. But our goal is to get these companies who want to do these complicated things, because they see more effort to do this, then using something from someone else, which they can't control. And it sounds like what you're saying as well as it could be complicated to people who aren't around programming, don't do coding or anything like that, they are end-users or whatever it may be. If you are a technical company by nature and have software developers within your staffing, this is not complicated. It's just another way of going at it?  Niko Sagiadinos: Yes. For example, with a room booking software. If you want to have room booking software, you can develop your own room booking software and implement it transparently in our system via a widget which is a bit technical, but you are able to control and make use of what you have written with our infrastructure. So you can use a software like a media player, for example, and say, okay I will run a playlist from 10 to 3 o'clock, and from 3 o'clock, this room booking software will run on this or any other kind of software, and that's possible because we have these open technical features. So is it a bit like the kind of emerging idea of headless CMSs? Niko Sagiadinos: Yes, a little bit. You can compare it to a headless CMS a little bit.  Because you're the control platform and distribution platform, but somebody could write a front end and use their existing room booking tools or whatever and it's going to flow through there? Niko Sagiadinos: Exactly, and another thing to say is that we are at the beginning at the moment. We started to get open, to get published and to imagine the SMIL player, the garlic player which I have written in 2016, the first three years did not even get any interest, because we are a small company in Germany, but we try to make our infrastructure step by step and build a SMIL based ecosystem and this ecosystem will grow.  At first, we had only the content management system. Now we have a player, a launcher, even the proxy, and this ecosystem grows and grows. The next step we have to do is to deliver more information on how to use SMIL?  There is a website from IAdea, but it hasn't been maintained for over six and seven years and so we have to do something to teach people. That's our goal.  Not only we have to teach people how they can use these things for their businesses, and this is a way we have to go. At the moment, we can not give a solution for everything, but we are on a way and time by time we can offer more and more solutions, more and more information, and the product gets “round” so to say in German.  I would imagine it's important to stress that this is not some little side project on GitHub or whatever. SMIL is something that was developed by the world wide web consortium, they are the same people who came up with HTML, right? Niko Sagiadinos: Yes, and it is used in industry. The HD-DVD started with SMIL, the MMS also uses SMIL, a new eBook standard also uses SMIL. That's not something we developed with a few students. This is an industry standard. It's no joke. It's global and I'm wondering why IAdea ten years ago didn't put more power to show the world that it's possible to make amazing playlists, produce amazing products with this language, and accept it as low-cost signage and went with that if you want to do real signage, you have to get other products and that's, for me, a reason why SMIL in the last 10 years did not get accepted. And is this a standard that's standing still or is it evolving just in the same way that HTML is evolving?  Niko Sagiadinos: It's now standing still, it's not evolving at the moment. It's stuck on SMIL 3.0, which is from 2008, but I've contacted the inventors of SMIL in the Netherlands, some professors and I contacted them because we need to evolve. There are some features that are missing in SMIL, and we tried to wake them up.  The standard is okay, but since 2008, nothing has happened like HTML, but on the other side there are many things you can do. HTML evolves because a lot of things have to come in, for example, 50 years ago HTML was not able to play video without plug-ins and things changed a lot. Internet Explorer was a market leader for much too long and had blocked the evolution of HTML for years and now with other browsers, Firefox, Chrome and Safari, there's much more moving in the web browser markets. And we are trying the same thing for SMIL. At the moment, it fulfills our needs more than we expected. My partner at first was skeptical too. But when I developed more and more features into the Garlic Player, he was stunned seeing what is possible and what only expensive digital signage systems are able to do, we can do with SMIL. So there is no reason to call it low cost signage.  Okay. What are the business arguments around working with SMIL versus an HTML5 based platform or some other developed platforms. Are they going to be more reliable? Is it gonna be less expensive? Is it gonna last longer? Niko Sagiadinos: Well, you are asking a developer a business question. (Laughter) You gotta sell it down the stream.  Niko Sagiadinos: Selling is more my partner's job, but I will try. The interesting thing is that HTML is okay for what it has to do. SMIL is another part and the web browser is not a digital signage player so as we say in German, we are comparing an apple with a pear and those are two different things. You can do digital signage with HTML, but you can even ride a bicycle to Tokyo. That's possible too.  I think SMIL is much more of a fit for the digital signage age than HTML. The business side is that with SMIL, you don't have any dependencies and HTML won't fulfill the needs of digital signage.  Your company's based in Hanover, Germany, and it's privately held, I assume? You guys own it. You're not owned by a larger company or a venture capital company? Niko Sagiadinos: We are a bootstrapped company, we started as two people and now we are a kind of German limited, GmbH, because we want to expand next year.  How many people work for SMIL Control? Niko Sagiadinos: At the moment, we are two people. My business partner and I so yes, we are a little company, but we also use external developer, and last time I started to work with Bulgarian developers and Greek developers, and because I'm a digital nomad, I'm commuting between Germany and Greece, because I like the weather in Greece much more and the food. You don't like Hanover or Northern Germany in February? Niko Sagiadinos: No, it's extremely cold and to be honest, November and December are the ugliest months because in Germany, everything is gray here and cold and Greece is so much better.  If somebody wants to find out more about your company, where would they find you online now that you have a website? Niko Sagiadinos: Yes, we have a website, smil-control.com. But the company name is Camel case. All right, that was terrific. Thank you for spending some time with me and explaining what SMIL is all about.  Niko Sagiadinos: Thank you for allowing me. I hope it was understandable. I know I was a little nervous and that's complicated because I'm not a salesman or a businessman. We are technically focused and I'm very stuck on this technical thing and I have grown up in 30 years of technology. So maybe for one or the other, it was a little bit hard. Sorry!  Oh, that's okay. There's lots of technical people who will be intrigued by this and want to know more, so I'm sure it'll work out. Thanks again.  Niko Sagiadinos: Thank you very much, Dave.

All JavaScript Podcasts by Devchat.tv
Catching Up on InertiaJS with Jonathan Reinink - JSJ 511

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Nov 30, 2021 80:04


Steve and AJ catch up with Jonathan Reinink, the creator of InertiaJS, a utility for seamlessly connecting front end Javascript frameworks with back ends to create a seamless and performant web app monolith. They discuss TailwindCSS and Jonathan's work at Tailwind Labs, and then get into InertiaJS, how it works, and many of the different features. They also discuss the new SSR capability currently in private beta, and Inertia's growing inclusion into other frameworks, such as Laravel Breeze and Laravel Jetstream. Panel AJ O'NealSteve Edwards Guest Jonathan Reinink Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialTop End Devs Links JavaScript Jabber: JSJ 443: All About InertiaJS with Jonathan ReininkJonathanReinink - Web designer & developerTwitter: Jonathan Reinink ( @reinink ) Picks AJ- Laws of UXAJ- - HTML: HyperText Markup Language | MDNAJ- Creeds of CraftsmanshipJonathan- Tailwind UISteve- Dad Jokes by Pubity - InstagramSteve- Dad Jokes - Instagram Special Guest: Jonathan Reinink.

JavaScript Jabber
Catching Up on InertiaJS with Jonathan Reinink - JSJ 511

JavaScript Jabber

Play Episode Listen Later Nov 30, 2021 80:04


Steve and AJ catch up with Jonathan Reinink, the creator of InertiaJS, a utility for seamlessly connecting front end Javascript frameworks with back ends to create a seamless and performant web app monolith. They discuss TailwindCSS and Jonathan's work at Tailwind Labs, and then get into InertiaJS, how it works, and many of the different features. They also discuss the new SSR capability currently in private beta, and Inertia's growing inclusion into other frameworks, such as Laravel Breeze and Laravel Jetstream. Panel AJ O'NealSteve Edwards Guest Jonathan Reinink Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialTop End Devs Links JavaScript Jabber: JSJ 443: All About InertiaJS with Jonathan ReininkJonathanReinink - Web designer & developerTwitter: Jonathan Reinink ( @reinink ) Picks AJ- Laws of UXAJ- - HTML: HyperText Markup Language | MDNAJ- Creeds of CraftsmanshipJonathan- Tailwind UISteve- Dad Jokes by Pubity - InstagramSteve- Dad Jokes - Instagram Special Guest: Jonathan Reinink.

No Sharding - The Solana Podcast
Brendan Eich - CEO & Co-Founder, Brave Software Ep #54

No Sharding - The Solana Podcast

Play Episode Listen Later Nov 30, 2021 24:49


Live from Breakpoint 2021, Brendan Eich sits down with Anatoly Yakovenko to discuss integrating Solana into the Brave Browser, the huge potential for a decentralized search engine and NFTs as entry point to the metaverse. 00:09 - Intro00:54 - Integrating Solana in Brave08:00 - Challenges with creating the browser09:23 - How to scale crypto to the general public11:57 - A Decentralized search engine14:46 - NFTs as entry point to the metaverse16:35 - Mobile vs. Desktop18:00 - Languages and smart contract development20:40 - How to grow crypto to mass adoption22:44 - Global Peer-to-Peer environment in Crypto Brendan (00:10):Great conference.Anatoly (00:11):I know. Thank you. I'm really excited to be on stage here with you. You're-Brendan (00:15):Same, [crosstalk 00:00:17].Anatoly (00:16):... One of my heroes. As a programmer, JavaScript is a language that really revolutionized how we do application development, how we build. It's the foundation of the web. And I often think of web 3.0 really just being the web, just part of the bigger web.Brendan (00:34):Yeah, me too. That's how the web grows, by evolution. So we think the web 3.0 browser should be the gateway to a billion crypto users. And we are therefore integrating Solana into Brave soon as we can. And here's the cool thing, this is an evolutionary path. We're going to make it so any dapp that is Solana enabled, wherever other chains, EVM compatible or Ethereum, whatever it supports, if it supports Solana as well, we'll make it use Solana by default. So dapp builders who build for Solana as well as other chains. In Brave it's going to use Solana. And that's going to just help, I think, pull all the dapps on the Solana.Anatoly (01:24):Super exciting.Brendan (01:25):You like?Anatoly (01:25):Yeah, it's wonderful. Yeah.Brendan (01:28):Let's see what else. What do we like about Solana? We like NFT games, we like DeFi a lot. We want to make it easy for users to earn and get yield without having to be super expert or do a lot of complex operations. So we're going to work on building that probably in the first half of next year into the wallet so that you can just robo-earn, robo-yield. And we want NFT galleries and NFT transactions to be super slick. I was inspired by the Jules Urbach talk earlier today, and the demo earlier here with NFTs, there were several of them actually, it's all good.Brendan (02:07):We want as many NFT marketplaces integrated as we can, so that's on the agenda. And yeah, [Radium 00:02:13] is there, of course. Radium's still earning, yielding good. The thing that we do now with basic attention token tends to have to settle on Ethereum and it's going to cost you gas. And our valued settlement partners like Gemini, Uphold bitFlyer in Japan, but once we're on Solana, I suspect that BAT, which is already reflected through Wormhole, proxied through Wormhole, might just find it's better to settle on Solana. What do you think?Anatoly (02:41):Yeah, for sure. Absolutely.Brendan (02:44):I'm giving you the softballs here. And we really do want to get this out to all users. We think, whether you're having a hard time in some part of the world where it's hard to get banks to let you save or borrow, or you're beyond banks like a lot of us are or want to be, Solana is the way to do it. And I mentioned auto earn already, got ahead of myself, but I think this is going to be huge. It takes some skill, you got to make sure if you get on the wrong side of yield farming, you go somewhere where the grass is greener, but we'll make it as automatic and easy as possible. And it's just so much better on Solana. I'm making you blush. And yeah, the dapp ecosystem is growing, but if we do this Solana default on multi chain dapps, I think we'll just pull every dapps that's really popular over that Brave users want, and I hope that's going to be every dapp.Brendan (03:37):So here's more NFT marketplaces. There are lots of cool projects in crypto, so we're not doing only Solana, we have obviously Ethereum, we're going to do Bitcoin in the new wallet. It's coming up fast, it's in the Brave nightly builds. And we might do other chains, but I think it's important to pick a chain as default. This is a lesson we learned the hard way with search engines, because when you make a search engine the default, first of all, you can get paid if you get a deal, not always true. And really the user expects to just type keywords into the address bar and search. We want the wallet to have a fast, good default and that's Solana. So enough said. And we're bringing it to mobile too. This is important. I think a lot of fragmentation has occurred due to how wallets are split across mobile and desktop. We're seeing some good mobile first or mobile also wallets. We want to do it mobile and desktop feature parody, evolve at the same time. And we're happy to do that with Solana's partner.Brendan (04:42):So the last bit of news is the BAT system is a triangular system that involves privacy preserving ads. And users opt into it to get 70% of the gross revenue. What we've built so far has a part of our BAT ad system requiring us to verify things, to be the trust third party, which is a security hole. And so we started a project called Themus and worked with several crypto projects to see if we could bring it to high speed chains that can do things, like you need smart contract systems for zero knowledge proofs, you need some part of it in the browser because you're measuring attention. You don't want to put your detailed attention log on any blockchain, however fast, because it'll fingerprint you. So we're using black box accumulators in the browser with Themus and we're then minting ZK proofs. And the cool thing about Solana is we can just put those on-chain, no aggregator, no trusted third party. So we're getting rid of ourselves, we're firing ourselves as a trusted third party. And that's something we're excited about.Anatoly (05:40):And that's awesome. That was, feels like two years of research. It took quite a while to get to that design.Brendan (05:47):And now it's going fast. I think now we've got good working relations with Solana and we can crank out the Rust Co, because we love Rust. Because I was executive sponsor of Rust at Mozilla, so I have a tear in my eye to see my little babies all grown up. And Amazon's hired a bunch of the Rust core team. It's okay, they need jobs. But yeah, we want BAT to be fast, low fee, DeFi base pair and for ads on Solana. So Brave and Solana are doing the new crypto and ad system and it's going to be awesome. Thanks.Anatoly (06:24):That's awesome. I'm a huge fan of the web, huge fan of all the work that you guys have done and Brave. And I remember pre-mobile days, I was working on Brew and I was trying to optimized the web and flip phones. And there was a brief moment where the iPhone came out, we had a browser, and it felt like the web has opened up. And then it just got away from us.Brendan (06:49):That's right. Jobs said when he did the iPhone one, he said, "The web finally works on a phone." And then the story I heard from somebody who would is that they had to port a bunch of games which were C++ or whatever, and they had to do native apps. And they never looked back after that. But I think the web can always catch up and should catch up. And web 3.0, if you have this evolutionary path with dapps and dapp triggers from webpages, then you just evolve into it.Anatoly (07:19):Yeah, that to me is the really exciting part, is there's now an opportunity to have cryptography power the next generation, how web is monetized. Whether it's through advertisement, like with zero knowledge proofs or through direct payments and micro payments. Do you feel like Apple's going to crush us?Brendan (07:41):People a few years ago were worried about this Facebook thing, Libra and now DM. And they got crushed because some politicians hate them. But Apple is very cautious, and if they're doing anything with blockchains, it's a ways out. And then when they arrive in, it's going to be the diva at the party at midnight, like, "Start the party now," and the booze has already run out. So we're going to drink all the booze first.Anatoly (08:06):All right. I'm down for that. What are some of the challenges with building a browser for general consumers, but also with cryptography?Brendan (08:17):This is the problem with browsers is they are universal apps. You spend a lot of your digital life or online life in them. And so if you make the crypto stuff be this expert only area, or it's scary. I use wallet apps, I use ledger hardware wallets, but it's a little bit scary because you feel like, "Did I forget my pin in or did I have to reset it and do the word list?" And there's some anxiety and fear of loss. We want to make crypto be a positive sum, that's why the robo-earn is important to us. Just like with BAT private ads, you could get 70% of the revenue.Brendan (08:53):So you're always building up your assets as well as spending or sending them. And it should be slick, it should be for e-commerce. You can even do things like dis intermediate Amazon. I won't give away all my secrets, but we think we can do that without having a bunch of JavaScript user scripts attack every merchant checkout flow. We think there's a way to get into the interchange charge and do it. And crypto everywhere. It should be slick, should be easy, should be comfortable, make you feel like you're going to win, not lose.Anatoly (09:23):What about custody and keys? How do I get my parents to understand this stuff?Brendan (09:28):Yeah, it's really a little different, but we're looking at Taurus, we're looking at various ideas for backing up your keys that don't just put it on paper and word list in the safe, which we've all been through. And in some ways, the old web went with username and password and had to add a second factor, which often had to be a temporary access number generator on your phone. So at that point you're almost as complex as self custody. I would say you just have this more conventional recovery path. You lose your phone, you know your email, you can try to prove that you're the same person to Coinbase or whatever. But I think self custody has a complimentary role and we want both. We want people to use self custody and be comfortable with it, so we're looking at all these usability challenges. And we think we can get it just almost as good. And then unfortunately the regulators insist, if you want to do Fiat on/off, you're going to go through a custodian.Anatoly (10:20):Of course. The challenges, that's the exciting part. No one has figured this out yet and we're going to dive right in and see, how can we actually scale crypto to the general public?Brendan (10:31):Make it easy for your parents.Anatoly (10:32):Yeah. Yeah, would love to see it. What do you guys see as the tension between the app store on the mobile device and the mobile web?Brendan (10:42):Discoverability is always a problem. And we don't want these brutal curators like Apple. So having lots of stores is good, but then you have the need for a search engine, which Brave now has, which is a private engine and also involve users opting into building the index incrementally, that's the web discovery project. So we're going to aim, because we're very crypto first and our ad sales teams, one of who's here, always looks at crypto options and NFT options, we're going to aim at making our search engine best for crypto. It already uses [inaudible 00:11:14] charting, and it's still in beta, but we're working out all the kinks, so I think search, the good old search we remember from 2004 when Google was great needs to come back and it needs to be the way you find stuff in marketplaces and crypto exchanges.Anatoly (11:29):That's awesome. What kind of information do you think users would want out of a crypto first search engine or curated environment that's different from the traditional web?Brendan (11:39):Search almost gets into, is somebody trying to SEO you and compete for keywords? We're aware of this problem and there's no silver bullet. But we think with crypto, you might actually have a better chance at mechanizing this and having a fair playing field, an automated system for finding the lowest fees and the best yields.Anatoly (11:57):Is there hope for a decentralized search engine?Brendan (12:01):Yeah. So I had a friend who was involved with pre-research, Rich Scrantom, and pre-research looks like it's running a bunch of nodes [inaudible 00:12:07] Google, which Google does not like. And if they're running on [inaudible 00:12:10] IPs, Google's going to shut them down or use their anti-bot team to take them out. We're building a legitimate search engine, but we can't decentralize the algorithm easily because search is sharing queries, looking for some kind of objective best results like page rank, the eigenvalues of the random walk. And decentralizing that is a research problem as far as I know. But we have an active team, we're evolving search and we need your help because we're trying to crowdsource the incremental indexing of the web, we're not trying to index everything from 1998 on. Only Google can do that. Hats off to them, but their time is passing.Anatoly (12:49):When I was growing up as an engineer, the web was just starting, I was really passionate about Linux. And I had this dream of a Microsoft-free personal computer. It feels like the web 3.0 is potentially a dream of ad exchange free, that parasitic Google free web. Is that possible?Brendan (13:13):If you don't collect the data you won't go wrong that way. There's still other ways that central powers can turn on their users and take advantage of them. But I think there is, and that means ultimately you might need hardware that's indie or that's user first. And Brave's not capitalized to do this yet, but I know people, including friends from Firefox OS, which actually after it folded at Mozilla, continued in [inaudible 00:13:37] OS. And there's an open source lineage that you can trace back. And people at Qualcomm, we both know-Anatoly (13:42):Of course, yeah.Brendan (13:42):... We are working on it at the time. So I think there's a chance for a new open source OS that has web 3.0 and none of this Java or swift native stuff. And JavaScript, web 3.0 All the way down.Anatoly (13:55):Are we going to end up building a phone?Brendan (13:57):Brave OS. I don't know, I'd have to raise some more capital.Anatoly (14:03):Yeah. Yeah, that's a way to nerd snipe me for a couple years.Brendan (14:07):But people need independent hardware that serves their interest first. Absolutely.Anatoly (14:10):For sure. It always feels like that's a really tough challenge. But every two it gets easier and easier, hardware gets cheaper and cheaper and the tools get better and better.Brendan (14:19):And then Apple has something new and shiny that the commodity hardware can't match for another year or two, but that's just the nature of the game. So I'm sure we'll have iPhones, but we can probably have BAT phones too. Solana phones.Anatoly (14:33):The BAT phone. I love that. The BAT phone sounds really cool. As you guys see the web 3.0 evolving, I think from your presentation, NFTs were such a huge focus as well. Do you think this is the entry point for the Metaverse as people call it or that really interactive rich environment with ownership of the stuff around you?Brendan (14:56):Yeah. I think you have to keep running at these problems. And usually if you're a startup and the timing isn't right, or something goes wrong, you run out of capital and then the investors reset, or maybe they try again. With crypto, we have this great ability to just keep leveling up. So we're seeing Bitcoin, now we're seeing smart contracts on Ethereum, now we're seeing Solana. And as you level up, you can start to do some of these things that seemed hard before. Like you want some kind of cryptographic proof of ownership.Brendan (15:26):I think one of the demos talked about this. You want to make sure that somebody doesn't copy the pixels. And if you get into VR, there's been interesting research on this. And my friends at [inaudible 00:15:36] have done some work on this. You can actually watermark in a way that's indelible. And if somebody copies your art and tries to remove the watermark, they degrade the quality, because it's been convolved with the luminance and the chrominance. So I have hopes for this being useful in games and connected verses. And to me, that's the Metaverse, it's not going to be something centrally planned at Menlo park by Lieutenant commander data.Anatoly (16:02):I hope not. What I see out of the gaming companies that we talk to is that, especially the ones that are crypto focused, is the one to build browser first games. Everyone that I talked to had this idea that as soon as you open the page, you jump right into the game. There's no sign up, there's no friction, your wallet is your identity. And you're just exactly where you left off.Brendan (16:24):That took a lot of work at Mozilla, by the way. We did [inaudible 00:16:27] JS and that led to web assembly. And you could show games, in the story, you can start playing them and then you just convert. I think it's a great model.Anatoly (16:34):Do you feel like mobile is expressive enough for that? Or is the difference between iOS and Android and desktop is too hard to actually make that work?Brendan (16:45):There's certainly a difference. Even with the latest chip sets, you're just not as fast, you have less bandwidth all around. But games can scale down because the view port's smaller, there's hope that you can use the kind of tricks that we see with the remote rendering, cloud rendering. So I think mobile is the future, but I heard this 12 years ago, people would say around Silicon valley, mobile's the future. And then they would say, "That means there's no desktop." And that is very false. Everybody with a laptop or any big enough screen and a keyboard is still very high value. And that means the economics there don't go away, it just doesn't grow as fast.Anatoly (17:19):That's true. If you look at the growth of the Solana ecosystem, a lot of the users are basically dust up only.Brendan (17:27):Yep.Anatoly (17:27):That to me says that a lot of folks, maybe there was a switch during COVID where we went from being so much immobile to where we're staring at screens again.Brendan (17:36):A bit of that. You go to India and a lot of people are mobile only, but you need both. And I think as mobile gets stronger, you're just going to see more parody, you won't see this need for apps, which is often artificial. It's like holding the browser back, sandbagging Safari a little bit. This is what my friends at Google, or one of them who went to Microsoft, always accuse Apple of, and it's not wrong. You got to give the browser it's due and then it can compete with native better.Anatoly (18:00):Got to ask you about languages.Brendan (18:03):Okay, [inaudible 00:18:04].Anatoly (18:03):How do you see smart contract development in the future as somebody that had incredible depth and understanding how application development happens on the web?Brendan (18:12):Yeah, I think the thing you're seeing with type script, especially with large teams, is more information that you need some kind of proof system or it could be just a warning system, but it's based on model checking. Often it could be based on higher level models than you can express in sound type system, which is something where there's just this timeless world of types that's potentially syntactically checked and prevents bad things from happening at runtime. You need dynamic systems, dynamic code, JavaScript, and the static checkers.Brendan (18:44):And you get the best of both worlds if you have really good ones. So I remember at Mozilla, we were investing in model checkers for C++ because it's memory unsafe. And you could build these higher level checks that knew about security properties you wanted to enforce. And I think this is what you're seeing with smart contracts. I was talking to somebody I met at the hotel bar about this, because it's still a very fruitful area that's had good research in computer science, programming language theory. And it hasn't always been brought to the programming masses like it should. There were companies like [inaudible 00:19:17] Covarity and others like that. The compilers themselves grew the ability to do plugins for static analysis. And now [LOVM 00:19:26] is there.Anatoly (19:27):Do you think that smart contract development needs to have a high level, easy to use language environment? Or can it be driver code?Brendan (19:37):Yeah, exactly. Driver code in the era of C was the worst code in the kernel.Anatoly (19:42):Driver code with Rust is a little bit less frightening.Brendan (19:45):In fact, a friend of mine who was at Microsoft at the time went to Mozilla and has his own startup now, did it at Microsoft, a checker for driver's C code. Which he could skirt the halting problem and kind of statically reason about it and say, "This is garbage driver code, send it back to the vendor." But yeah, I think you don't want to have happy, fun, JavaScript looseness if there's big money at stake. So I think it's important to have the right tools with the right static and dynamic checking.Anatoly (20:13):Do you think smart contract development is strictly financial or are we going to see things that are not financial that you can actually [crosstalk 00:20:21]?Brendan (20:20):You'll see things that are not obviously financial, but they'll turn into reputation in a game or gifting and those tend to matter too. So you still don't want too many dynamic errors.Anatoly (20:32):That's true.Brendan (20:33):So I talked about this in my chapter in coders org, I'm still a fan of static, even if it's unsound semi-static checking.Anatoly (20:40):What do you guys see as like the opportunity for us to grow crypto to a hundred million users, actual signers?Brendan (20:49):Yeah, I'd to get Brave to that scale in a year or two. It depends on everybody here and others. It also, I hate to say it, depends on the nation states of the world not doing something adversarial. But I think given the state of the world, not a great state, but there will always be options to do things with crypto. The internet routes around censorship, and that's true in the web 2.0 And the web 3.0 world. And it's true with blockchains. You still have concerns you have to fork to undo the censorship, but at least you have options. DoAnatoly (21:26):What kind of applications do you envision will actually drive that growth?Brendan (21:30):I think at first it's going to be people using crypto for payments and for DeFi. And some leading edge of that user base will be getting more sophisticated in doing other things. But just having things like gift cards, where we often find that they're useless points, even if we can use them or Congress passed the law to don't expire, we still just don't use them. We should have much more liquidity. We should have liquidity across all kinds of assets. And this is where you start talking about tokenized securities, and can you have primary and secondary liquidity for companies? I think if you're as old me, you all had a tiny piece of some startup that went sideways for 10 years and then sold. And you couldn't trade it easily. And you might have wanted to do that because you might have been squeezed out when it sold. So there's lots of room for blockchains to solve these problems. I think in general, connecting people more directly getting rid of these officious or censorious intermediaries. A lot of room for application.Anatoly (22:29):In this new evolution of the web, I often describe crypto as a fully connected network, as opposed to a social graph, like on Facebook.Brendan (22:40):Yes.Anatoly (22:40):Do you think that's true? Do you think we're going to enter a stage where I am effectively with my cryptographic signatures, I'm in this true global peer to peer environment?Brendan (22:50):I hope so. I showed at web summit last week, I showed the slide with the correct diagram, which is more like a mesh for decentralized, and the incorrect one, which sometimes is called decentralized, which is really distributed, but it's mostly tree structured. Or if it's a graph, it has a dominating spanning tree. That's Google, that's Amazon. So with projects like Helium, with web RTC making it so you can make connections into the endpoints instead of only out. In the old days in the nineties, we could only make TCP connections out from the browser. I think we're heading toward this world. We have to build it iteratively and collaboratively, we have to get around the concrete firewall problems that web RTC mostly got around, it's still a little dodgy. And I think that is the future. I think we should all have Helium nodes if we can. I'm a fan of the project.Anatoly (23:38):That's awesome. The idea of decentralized browsing on an open source phone connected via an open network.Brendan (23:49):Low raw radio.Anatoly (23:50):Yeah, run by the people. Accessing Solana, that would blow my mind.Brendan (23:55):It sounds too good to be true, but I think it could be true, especially if we build it carefully and quickly enough and get it out there and make it usable, which is why I've always wanted to make Brave be about crypto. Even when we started using Bitcoin for our prototype, it was clear once you shield the user by blocking all those trackers, you break all the economics that pays advertising money into the publishers after taking a big slice out for the middlemen like Google. And if you cut that out, how are you going to reconnect it? It's crypto, peer to peer.Anatoly (24:26):All right, let's do it.Brendan (24:28):Awesome.Anatoly (24:28):I'm excited. So thank you, Brendan. Thank you so much for doing here, for working with us.Brendan (24:34):Thanks.

Software Social
Solving Your Spouse's Problem: A Conversation with Jordan O'Connor, Founder of Closet Tools

Software Social

Play Episode Listen Later Nov 30, 2021 46:40


Follow Jordan! https://twitter.com/jdnocEvery doctor is concerned about your vital signs, but a good doctor cares about your overall health. Your website deserves the same care, and Hey Check It is here to help- Hey Check It is a website performance monitoring and optimization tool- Goes beyond just core web vitals to give you a full picture on how to optimize your website to give your users an optimal, happy experience- Includes AI-generated SEO data, accessibility scanning and site speed checks with suggestions on how to optimize, spelling and grammar checking, custom sitemaps, and a number of various tools to help youStart a free trial today at heycheckit.comAUTOMATED TRANSCRIPTColleen Schnettler  0:02  Every doctor is concerned about your vital signs. But a good doctor cares about your overall health. Your website deserves the same care. And Hey check it is here to help. Hey check it is a website performance monitoring and optimization tool. It goes beyond just core web vitals to give you a full picture on how to optimize your website to give your users a happy experience. It includes AI generated SEO data, accessibility scanning, and site speed checks, with suggestions on how to improve and a number of various other tools to help you start a free trial today at Hey, check it.comWelcome back to the software social podcast. I'm your host today, Colleen. Today I am super excited to have a special guest on the pod. Jordan O'Connor, the founder of closet tools is today's guest. Thanks for showing up today. Jordan, I appreciate it. Jordan O'Connor  0:56  Yeah, no problem. Thanks for having me. Colleen Schnettler  0:58  So I specifically wanted to ask you here because your Indie hackers interviews was one of my favorites. And I'm sure you hear that a lot. Do you hear that? A lot? Jordan O'Connor  1:07  I've heard it a few times. Colleen Schnettler  1:08  Yeah. Yeah. So for those who have not heard your Indie hackers interview, could you tell us a little bit about what closet tools is? Jordan O'Connor  1:17  Yeah, so closet tools, I started closet tools almost almost four years ago now. It's basically an automation. It's software automation for Poshmark. So Poshmark is a retail selling platform. So it started out as mostly just people selling used women's clothes, it was mostly women selling used clothes on there.And the way they built the platform is more like social media than it is like, you know, like, you know, like what you would think of ecommerce is like a storefront or something like that. And so the way to get exposure to your closet, your profile, you have to do things like sharing and liking and commenting and all these different social engagement signals. And that's how you get exposure. That's how you get followers. That's how you get, you know, eyeballs on your stuff, so that you can sell stuff. And so that takes a ton of time. And my particular customer, which would be like a reseller, they don't really have time to be on social media all day engaging and stuff like that, like they just want to sell clothes. Most of them sell on eBay, they sell, you know, on their own storefront. So they just want to sell stuff. And so that's what causes tools does, it does a lot of those engagement things for them, it'll share their items throughout the day, it'll automatically respond to different events that happen if somebody likes an item, it'll automatically send that person an offer with a discount stuff like that. So it kind of automates a little bit of the sales process for them. So yeah,Colleen Schnettler  2:46  so Poshmark is like eBay, but fancy, right, like higher high end.Jordan O'Connor  2:52  It's no, it's definitely it's definitely I would say it's not that eBay is high end, but Poshmark scales, low end to high end, you can you know, you can find, you know, you can find like really nice purses or whatever on there and stuff. Or you can buy, you know, a $5 You know, screenprint t shirt, like you can buy, you know, anything you want on there, most of the appeal is that most of the items on there are like used. So you're getting get a discount on some item that's lightly used that you would normally pay a lot more for. So that's kind of, you know, the the corner of the market that they tackled, there's also a lot of new items on there and things like that, too. So, but yeah, the thing that's weird about it. So like you have like a closet, it literally is like like Instagram, so you have your closet, and it has like all the images of like your items and stuff that you're selling. And each post has, you know, a common section, people can like it, they can share it themselves to their followers. And when you share to your followers, your item, they're basically when you share to your followers, that item shows up in their main feed. So like you can go into the app and you can like search specifically for like, hey, I want like Nike shoes, or whatever. And then I'll just come up with Nike shoes. But if you just kind of like go into the app, and you have like the main feed, just like any social media platform, whatever people are sharing is what's going to show up there. And so if you're not constantly sharing, then you're not going to show up in that main feed, and people aren't going to randomly stumble onto your profile. But you literally have to physically click like two buttons for every item you want to share. And a lot of my customers are actual, you know that this is their business and they have 2000 3000 4000 items. And it would take them an hour or two just to go through and click click, click, click click. So it and that could be time there's been doing other things like even literally just like packaging items to sell send out and stuff like that. So So yeah, it saves them a ton of time, and it ends up making them more money in the long run just because you know it's doing things for them. So it's pretty, it's a win win. It's pretty cool.Colleen Schnettler  4:48  So how did you get that idea? Were you selling stuff on? Poshmark?Jordan O'Connor  4:52  Yeah, so my wife started selling things on Poshmark at the time. We kind of need some extra income and she was like no One of her friends actually introduced her to Poshmark. And so she jumped on and she was starting to sell stuff. But then right away, I kind of was like, Whoa, you're spending a lot of time, you know, night sharing and doing a bunch of stuff on there. I was like, and it was right around the time I was kind of learning web development, things like that. I had already knew how to code and stuff. But I had never really done much web development. And I said, Hey, I think I can write like a little script that kind of like automates that for you. Like, you just press a button, and it just rifled through and shares all of your stuff. And so that's what I did. And so that's how I made the first, you know, like, kind of the first version. And for a while, I just, um, let her and her friends use it. And they thought it was awesome there was that it was really cool. And all it was was a bookmarklet. So like in, you know, browsers, you can just embed JavaScript code right in the bookmark, and you just click it and execute it. And it just like, yeah, you went through, it wasn't smart, or anything, had no GUI or anything like that. I just did it. And they thought it was great. And they were doing well with it. And then I blogged about it on my personal blog. And over the course of like, six months, I started getting like a hand few handful of emails from people saying, like, Hey, I found this, you know, this thing that you posted, like, how do I use it? Like, how do I get it working, because I want to use it. And even still, at that time, I had no intention of like selling it, or like making a business out of it or anything like that. So it was like, I was just trying to be helpful. I was like, Yeah, sure. This is how you use it, you just let you set it up. And so yeah, it wasn't, like I said, it was like six, between like six to 10 months before I was like, Oh, I can actually probably, you know, make a front end for this actually build some more features and make it a little smarter and actually sell less so.Colleen Schnettler  6:33  So was this your first business idea?Jordan O'Connor  6:37  Well, um, it was, it's my first like software business idea I had for a while before that, I was I knew I wanted to kind of break free of employment, I wanted to do my own thing. So I had already learned. I learned web development, I learn how to make websites, I learned SEO and I learned marketing, copywriting sales, I kind of like went down this like course track of just like, take a course learn a skill, do it for some people to practice it. And then I kind of like nail down all these things. Yeah, and the first product idea I had actually, it was related to my wife as well, she does art she does like water coloring and hand lettering, things like that. My idea was to make a black paper notebook. And at the time, none existed and none existed with any kind of like premium features. Any of the ones that exist over like, you know, construction paper or something like that was this like awful for artists. And, and that actually would have done really well. But I didn't really have the capital upfront to actually invest in, you know, a physical product. So I ran a Kickstarter, and I think I needed like 13k. And I got like, 11k I ran, I ran probably like, I don't know, I was like $1,500. In Facebook ads, I had a couple months where I was like doing Instagram stuff, and actually learned a ton from that. And I'm kind of glad it didn't work out. Because I feel like what I do now is a lot more. I don't know, it's just more the way I would like to do things. But I learned a ton from that. And that was kind of the first thing I didn't. So the closet tools, like the first thing that I made for my wife was kind of right on the heels of that. And so like it just kind of switched over from there. But yeah, I was trying a whole bunch of stuff even before that, what I was doing when I was doing take taking the courses and learning things as I was actually trying to make, like just do freelancing basically where like, I would learn SEO, and it's like, hey, I'll go out and like do SEO for people. But then it would always get this weird feeling where like, yeah, you know, like, especially with like SEO, like, if you compare some of the like the value that you can actually get out of it. It's like ridiculous. And I'm like, why would I do this for somebody else, I got to figure out how to do this for myself. And so that was I kind of kept doing that. And then I got to the point where I was like, Okay, I'm gonna actually do this, I'm gonna pull all my skills together and actually build something. So yeah.Colleen Schnettler  8:55  So I'm really curious about this. I didn't realize when you said freelancing, I just assumed you were doing it as a developer. So you like, took an SEO course. And you're like, hey, let's see if I learned something. And you freelanced as an SEO you who are an engineer, freelance as an SEO consultant. That's right. Yeah, IJordan O'Connor  9:14  mean, I didn't. Yeah, I wasn't like, I was mostly just trying to get something to work. So like, I was just, you know, trying to do it. And also, I kind of just for some reason, I had this mindset of like, I need to practice this stuff. I need to actually get out there and do this stuff, if I really want to know it. So you know, I wasn't really like charging a lot or anything. Sometimes. Sometimes it was like, Hey, I just want to do this for you. And so, so yeah, it wasn't like I was trying to like establish myself as a freelancer, but it was more like, I want to try this. And if the freelance thing works, and it takes off, and this is good, then that's fine. If it doesn't, I'm going to learn these skills and I'm going to you know, use them later on kind of thing. So, but yeah, I was doing that for a while. And yeah, like I made a whole logistics trucking app. front end back end for a friend of mine, and he still uses it today for his trucking company. And so yeah, I did a whole, I did a whole bunch of stuff. Before I really got before I discovered that I wanted to make a product instead of like doing a service. And that was mostly just based on like personality, a lot of times, what would happen is I would start doing the work, and then they would have their opinions and their thoughts about how things should be. And I would be like, No, I'm kind of the expert. I think I know, I think I know what to do here. And they would, they would always contradict, and I just didn't really feel like messing with that. So I was like, the only way I'm gonna make money is if I if I can make a thing and sell it. And if people don't want it, then they don't have to pay for it. And then I don't have to deal with them, you know, in their opinions and stuff. So yeah, yeah. So that way, so I had to go on that journey too. So yeah, a lot a little a lot a little journeys. It was a Yeah, it was a couple years of just just doing stuff, just taking action, and then kind of landed on closet tools.Colleen Schnettler  10:59  I think that's so important. You said it was a couple years. Like I feel like we have this perception in the indie space. There's so much information. I you know, I launched my first product in February, and I feel this hard like, some guys like I made $100,000 In three months. And I'm like, What did you make? I love so I love that you I feel like a lot of your messaging from the podcast and your Twitter is you are like, hey, yeah, this thing was super successful really quickly. But I had five years of background that helped me build up the business to what it is.Jordan O'Connor  11:31  Yeah, yeah, I think I, I don't know. Yeah, I always, um, I always like to try to optimize for long term results. And a lot of those people are just, you know, really optimized on short term results, it is like this, like, oh, I made this much in one month. But then if you talk to them six months later, they haven't made anything more, it just, they had this little spike, they went up on Product Hunt or something, and, you know, whatever. And so like, to me that, you know, with a with a wife and kids, that's not really sustainable, like you can't just have a spike, and then like, kind of live off that for you know, the rest, you know, so I had to find something that was very stable and sustainable, and then actually grow over time. And I don't, I don't really know why I had that perspective, early on, I think it might may be just a personality thing. But I think optimizing for long term and actually developing great foundational skills, and then building on that organically over time, is so much better, long term, because then you build something that is just growing, you know, on its own. And you don't really have to do too much to it to make it you know, to force things to happen to you know, make it seem like you're making a ton of money or something like that.Colleen Schnettler  12:41  So the skills you were talking about, like you said, you spent a lot of time in SEO, and you learned how to do Facebook ads. So he said, so So were there any other like pivotal skills, you think that really helped you see this opportunity and capitalize on it.Jordan O'Connor  12:57  Trying to think of the different courses that I took, I think there was really it, it was web development, SEO, and then Facebook ads, Facebook ads was unique, because it taught a lot about sales without teaching sales. It was like it was it was like, you know, because you know, a lot of Facebook ads is mostly just like copywriting expertise, because you're trying to just get something really catchy. But most it was always this weird thing. For each space. It was always interesting, because like the web development course was like you're trying to teach web developers that want to get a job. So that was like the outcome of the course. But then like SEO, it was like, we're gonna teach you SEO, so you can start an SEO agency. And then like, the Facebook ads, it was like, oh, like you can use Facebook ads to sell someone else's product and get like, you know, affiliate revenue or something like that. So the outcome was always different than what I wanted. But I picked up the skills, you know, throughout that. And so because of that, I think I was able to glean a little bit of a different perspective on it. So like with the Facebook ads, I wasn't just trying to optimize my ROI, or I guess, what would you call it Roa? You know, ad spend. So, like, I wasn't trying to do that, I was trying to learn how to make really great, you know, copy and actually sell something to somebody that just saw it for the first time. And they're like, and when they see it, they're like, Oh, this is something I need. And same thing with SEO, I wasn't trying to build a big agency, I was trying to figure out the most optimal way to do SEO correctly so that I could just get organic traffic over time. And same for web development. I was just learning how to make websites, you know, for myself to make my own business not to you know, do it for other people. So yeah, so I mean, I think those are the foundational skills I think those three and then combined with writing over time over the course of the the whole well now it's been like, you know, five years ish, six years and I've been kind of doing that So I've been writing the entire time, I used to write a lot more personally back then. But it was more rambling, it was more like, this is what I think I want to do. And I'm learning this thing. And this is you know, so it's kind of documenting the journey, but also documenting some of my thoughts and emotions around what I was doing. But I think over time, I kind of honed and honed in on a good skill of writing. And I think writing effectively, is one of the best ways to save time in the future, especially when you make a product. You know, if you write really good documentation, if you're really good at communicating via text to your customers, if you're really good at copywriting and selling on your website, then you have to do less one on one sales and saves you time so that you can do other things. So I think writing is like huge. So I think those are kind of like my bundle of skills that I at least I do. And I advocate for other people have different personalities, some people really like going and doing one on one sales, I don't really like doing that. I've never asked a single person to use Clausa tools individually, you know, like they come to my website, they see whether or not they want to have, you know, want to use it. And you know, that's it. I don't have to talk to anybody or anything like that. So. So yeah,Colleen Schnettler  16:10  that's really interesting. You mentioned writing. So I was at founder summit last week in Mexico City. And we had a whole workshop on writing. So tell me, do you think the thing that I think I struggle with a lot is, it's like when you have such limited time, and you have children? So you understand? What what is the best way to use that time? So tell me, do you think your personal blog helped you become a better writer and communicator and was worth the time that you put into it?Jordan O'Connor  16:36  I do. I do. I think, um, I think it was a combination of that. And Twitter. For me. Twitter is interesting, because a Twitter is more where I used to kind of test writing, where it's like testing for feedback on writing. And especially in regards to like context and nuance because Twitter has absolutely zero context and nuance and most tweets. So if you can write in a way that has enough context and nuance where people get it and it clicks with them, then that's effective writing, because you can write very simple, clear small statements that actually contain enough information for people to like, get something out of it. And so I think that actually was really helpful for effective writing, but then having the blog to document the journey along the way, really helped me refine my thoughts, and then also keep my thoughts in line with like, Okay, this is a long term vision, this is what I'm actually doing. This is what I'm working on, here's how I'm actually progressing towards the goal. And so I think the personal writing, yeah, is more about like staying on track. And Twitter was more about writing effectively, and, you know, writing in a way that, you know, helps people understand, you know, what you're saying better with with a limited amount of text. So, but yeah, I think, yeah, I think writing is super crucial. And I think writing is, you know, just so foundational, even for any other form of content creation, you know, it most of the things can start with effective writing, if you have an effective, you know, piece of writing, you can make a movie out of it, you can make a video out of it, you can make an image out of it, you know, you can make a podcast out of it, you know, there's a lot of different things you can make out of text. Whereas the opposite isn't exactly true. Like if you, if you have a video, it might not end up being a great text piece, you know, like, it doesn't always go the opposite direction. Like even the transcript for this podcast isn't really ultimately that valuable, like you people still have to read through an hour long of text. Whereas if you have effective writing, like you can have just one idea, and you can make a whole hour long podcast episode on that one idea. So that's why I think I think writing is really, really foundational. I think it's, I think it's great.Colleen Schnettler  18:49  Yeah, that makes that makes sense. So, when you started closet tools, tell me what was going on in your life at the time.Jordan O'Connor  18:59  Um, quite a lot. So um, when I started closet tools, I actually was getting to the point so so if we backtrack a little bit, I, I went to RMIT college up here in New York, for electrical engineering. So I graduated as an electrical engineer, and I started working and I was making decent income was like 80k years, something like that. But right around the time I got hired on I got married, and then about and then we got and then we actually quickly had our first son, which was like, not really planned, but it wasn't like the biggest deal we were like, Yeah, we plan on having kids anyways or like whatever. But it kind of financially things kind of just kept eating away. And so like once I started to start paying student loans and then like I had a kid coming and there was just like all these expenses piling up and my income wasn't really like scaling to that like it was just fixed. So like more and more things are eating away my income and I have like no spare income to do anything with My wife, we had always planned on her staying home with the kids. And you know, like, now we're doing homeschooling and things like that. So that was always the plan. So I was like, I need to figure out something here to like, actually make more money. And so when I started closet tools, that was actually the last thing I was gonna try, it was either that or like, pick up a second job somewhere, like, do something to like, kind of just expand a little bit, so that I'm not in student loan debt for the next, you know, 45 years of my life or whatever. You know, like, that's, I just didn't want that at all. And so, so yeah, so that was like, kind of going on. So I had a little bit of a chip on my shoulder, I had some urgency to be like, Okay, I need to make something that works. And so I think that's partially why I went with closet tools, because I knew something was working. My wife really liked it, her friends really liked it, I was getting emails about it. So like, it was like this thing, where it's like, okay, I have all these signals that like, this thing is probably gonna, at least, you know, do something I can make, that my intention was to make $1,000 a month, I was like, hey, like, if this thing makes $1,000 a month, great, like, you know, help, you know, pay some bills, you know, and I can like, catch up on some stuff. And like, maybe, you know, it, put some, you know, put some money into savings and stuff like that. So, so yeah, it was a really, really a pretty desperate point in my life. But it was, it was, I was very stubborn, though. Because I really wanted something that I wanted, I didn't really want to, I didn't really want to get a second job. I didn't want to just like make money to make money. I wanted to do something on my own terms, where like, I had the freedom and flexibility to still spend time with my kids and my wife, you know, still come home in the evenings and have, you know, the time together with my family still do things outside of work and things like that. So it was like, I was very, it was a it was a pretty like urgent time. But I also was very picky and stubborn. So like, you know, you know, somebody might say, Hey, you could have just been less stubborn, and you wouldn't have had any of those issues. But like, if I was less stubborn, then I wouldn't have what I had now. So. So I don't know. So it was a little bit of a balance of that. And I think that's partially why it took a little bit longer to get to a point where something happened, that actually worked out really well, because I had to put all those pieces together to make something that worked for me personally.Colleen Schnettler  22:06  Yeah. So and that that makes sense. So when you were like, What was your day to day like? So you had a full time job? You're married? You have a baby? Like, how did you do that?Jordan O'Connor  22:19  Yeah, so I started right before my first son was born, I started getting up really early. At that time, it was actually really crazy. And I don't know, when I was younger than so like, I had some energy. Now I can't do this, but I was getting up, I was going to bed or like, you know, 1011 I was getting up to like for, like, you know, like, that's it. And so but what I would do is I would actually just work on side stuff, all morning until my day job. And so like, the earlier I could get up, the more I could spend time on that. And the reason why I did that there's a few reasons why I like getting up in the morning. I still do it actually, I get up at five every day. Yeah, there's actually a lot of reasons when you have kids. Nobody's awake. So nobody's like, you know, there's, there's not that like, you know, like, the family is like always distracting. And because they're always distracting, but there's no chance of a distraction, like people are sleeping, they're definitely sleeping, everybody always sleeps until like this time. So like, you know, there's no chance of distraction. So you can enter into work and get focused and understand that like, Okay, I have this block of time, that's, you know, undistracted. The other thing is, like, if you work in the evenings, typically you're pretty tired by the end of the day. And you're also just kind of, you're basically saving your worst amount of energy for this thing that you actually want to be doing. Whereas in the morning, you're pretty fresh, usually, I mean, as long as you just look good, you feel pretty good. You're pretty, you know, your heads, and you know, pretty, like, I'm pretty focused, you're not distracted by a bunch of things, you're not like responding to emails, or whatever your day job is and stuff. So like, to that morning time is pretty free to like, focus and do good work on whatever you want to do. And so that's what I did I for, you know, for the first couple years, I spent a couple months, you know, on each of those different kind of core skills that I learned web development, SEO, you know, Facebook ads, and things like that, you know, I would just take those first couple hours a day, whether it was like taking a course or it was doing the actual work for somebody to practice or doing the work for myself, or it was personal writing, you know, so like, it was like that. So really, I built most of everything in those couple hours every morning. And so that, that to me, like I was able to get a lot of work done in those couple hours a lot more than I was even able to get done like a day job. And so for me, that's kind of how I've modeled even causal is now like, I don't spend more than I don't know, maybe like three, probably four Max hours a day on it. You know, just because you don't really need that much time. In a day to be that productive, you know, the eight hour workday for you know, most jobs is mostly so that you have a window of time, if you want to reach out to like a customer or you want to, you know, be available for a customer to call you or like to reach out to a different company or stuff like that, like there's a window where you like you can do that. It's not actually like you need eight hours to get effective work done. I don't even think you can do Ultra focus work for eight hours, like maybe four hours max, before you're pretty burnt out. So So yeah, so that's, that's how I did it. So I say it all, you know, I used all of my creative energy in the morning to like, do that. And then I just kind of coasted at my day job. I mean, I basically, I got to the point where like, I did really well there. So I worked at Corning, and they make they make advanced optics, which one of the products you make is like a lithography stack. So it's like a stack of lenses that like Intel would use to image their processors. And it's pretty complicated. I didn't actually know anything about the optics, I wasn't an optical engineer, those guys are like nuts. So, but um, I was like in the testing department. So like, I would build systems that would test the quality of the optics. So I did like lasers, and I moved motors to like, move the lenses and stuff. So like, I got to the point where I had like really good autonomy in that position, because like I kind of had done all the things I needed to do at least one. So like most projects I was doing, I was reusing old things that I already did. So then they would still give me the same timeline on a project, they'd be like, hey, we need this piece of software and this like thing done in like a month. And I'd be like, cool, and it would only take me like a week. So then sometimes I did actually have time at work to you know, to do like causal stuff into like, you know, like, if something was broken, I could actually fix it right then. Yeah. And you know, as long as I was writing code, it looked like it was working. So like,nobody really questioned it. So. So yeah, it was, you know, I, but I came to my management at some point. And it was like, annual review. And they're like, oh, yeah, you're doing good. Like, is there? Like, you know, is there anything that you you know, like, do you want to, like, go big? Or like, what do you what do you want to do here, I'm like, I want to be like, really low key, like, I don't want to do you know, I don't want to be the super save the company, dude. You know, like, I just want to like show up, you know, you give me my work, I'll do my work. And then I'm gonna go home to my family. So I kind of had this like, this vibe of like, almost like a little bit untouchable, where like, you could send me stuff and like, I'll do great work. But you're not going to like make me stay over time and like, do all this bunch of crazy stuff. And like, I'm going to do things at my pace. I'm going to do it, you know, so it's like a little bit of a, so he was just kind of like that. And so yeah, so I don't and I don't know, I don't know if that's actually advice to like anybody else that wants to, you know, do their own thing if that's what they should do. I have no idea. But I know for me, like energy wise, I didn't have the energy to do all that in the morning, and then go to work and then be like, you know, crazy and do a bunch of crazy stuff. So I had to balance it a little bit.Colleen Schnettler  28:06  Yeah, I am a morning person. So you're speaking my language here. But I have not tried 4am That's pretty intense.Jordan O'Connor  28:13  Yeah, don't do for now. I do five at least Yeah. So yeah. SoColleen Schnettler  28:16  so when you were building the business, though, so you would do like four to eight and then drive. That's back in the olden days when we the drive to work. Work like eight to five?Jordan O'Connor  28:28  Yep, yeah, yeah, that's what I would do. And I did it day in day out. And so I did that for close to two years before. Well, I did that. I guess I did that for like a total of three years. So I did that for like a year. And then I kind of want to start a closet tools. I worked a job for almost, it was like a year and a half that I worked at job and did closet tools at the same time. Okay, so So yeah, so yeah, yeah, that's, that's just what I did. And looking back, it was really crazy. But it Yeah, it worked. You know, so yeah.Colleen Schnettler  29:04  Yeah, I love your point, too, about like your project, getting your best energy in the morning, as opposed to keeping your project till you know, seven to 10pm at night kind of deal. So, it sounds like with closet tools. There was a real poll from your customers. Like you knew you were onto something because people were cold. outreaching to you.Jordan O'Connor  29:24  Mm hmm. Yeah, so um, yeah, I don't know if you want me to just elaborate that. Yeah,Colleen Schnettler  29:30  go for it. SoJordan O'Connor  29:31  basically, what happened is, I you know, I started learning the SEO stuff. So I had already kind of, you know, SEO optimized my personal blog. So when I wrote about this, you know, this topic on my personal blog, I titled it like, you know, like Poshmark automation or something like that. And I just had some instructions on how to you know, how to run this script on your own browser. And so, you know, a lot of those Poshmark related keywords were pretty easy to rank for. And my site had a little bit of a already, so it was pretty simple. But so like, because I had tapped into SEO vein, I already had that, you know, like kind of that in to be able to get people to see what I was building. And then my personal website just has my email and stuff. So like they were able to just email me or whatever. And so, but from there when I actually started closet tools, I actually went on Reddit, I went to the Poshmark subreddit. And I said, Hey, I have this free script. You can you can try it and keep it you all you have to do is sign up on this email list. And you can use this thing. And then what I want from you is I want to get feedback as to what you want built around this thing, like what other features would you want? How would you use this? You know what, you know, what things do you want to see that can help you sell more stuff? And so that's what I did. And I got around like 200 signups in like a day or two. Wow, for that free script. Yeah. And so and that was kind of the the start of everything. And so then what I did was, it was like, I did that post got the 200 signups people tried out the script. And then like a week later, I sent out an email to that list saying, like, Hey, give me some feedback. What do you want to see, and then I got a bunch of emails. And then I spent the next like, four weeks building out some of those features. And then I spent like, the majority of that time just integrating stripe, because I had no idea how to do it at the time. So I had to figure all that out. And then and then and then I lost it like a month later. And I had 10 paying customers right out of the gate. So it was like 300. MRR, like the gate basically. So yeah, so So the initial start wasn't based on SEO was based on Reddit. But I also got banned from that subreddit because they don't like the self promotion and stuff. So it was like kind of this one shot thing where I was like, I'm going for it. I'm gonna sell this thing, and it worked. So then from there, from there, I started writing content. And you know, the SEO, traffic started to take off more. And that's how I've basically built it to where it is now. SoColleen Schnettler  32:06  yeah, and word of mouth to probably I mean, people love to the product. It sounds likeJordan O'Connor  32:10  Yeah, yeah, definitely. I mean, yeah. So I say SEO, SEO is the only thing I had control over that, you know, did that. But certainly, yeah, word of mouth, everybody. You know, a lot of my customers have another friend that used it, and they refer to it and stuff like that. And then later later on, probably about two years, and I created a referral program, which is interesting, because like the referral program itself hasn't been like a, like a smashing success. I think it's brought in, I don't know, I think it's like 15k over, you know, a year or two, but like, the whole gross I've made like, I don't know, like 900k. So like, it's not like this huge percentage. But it did bring in a lot of word of mouth. But then also what happened is it brought in a lot of backlinks, which reinforced a lot of my SEO because when people posted their affiliate link, it just linked back to the website. So it was kind of this like a little it was more about the SEO engine for me rather than it was like, you know, the referral program. So yeah, but it also gave a reason for people to you know, talk about it, because they could get, you know, a kickback or whatever. So,Colleen Schnettler  33:14  right. So it sounds like that was a win win, even if it wasn't a huge, like windfall. So let's talk about what your life looks like now that you know you are successful. Your business this is not that you weren't before. I'm just saying likeJordan O'Connor  33:29  even that I am now I don't know. Yeah, that's what it's all relative. I guessColleen Schnettler  33:33  it's it is all relative. That is true. So when you're building the business, you had these super long days. What do you do now? What is your day look like now?Jordan O'Connor  33:42  Yeah. So now we have three kids. We have another one on the way actually, congratulations. Yeah, thanks. Yeah. So February, that'll be you know, I'll be it'll be, it'll be interesting to see how much work I get done. But, so actually, now, like, we have a pretty strict schedule, now, we just kind of came up with it, we've over the course of like, the last year or two, we've been trying to come up with a schedule that works for both of us. And most of it centers around, like, my wife wants to feel put together and like, you know, like she has the house under control and like the kids under control and like you know, like that is gonna run smoothly. And, and but then for me, like, you know, like coming fresh out of like, you know what I was doing before I was like, oh, like I need like that whole morning to just do my best work and then like, you know, free food so but that didn't really work out for her too well, because like she would get up with the kids and the whole day was basically a mess from the start because it's like you're you get up and kids are demanding a bunch of stuff and you're just like, I don't know what I'm doing like, and so now I take the kids as soon as they wake up so I get up at five and I work for I work I kind of I don't know I go back and forth and what I use my morning time for now. And I think if I ever built a future business, I would take them out in time and do that. But now I use, I work from five to seven, and my daughter wakes up at seven, she, we have her train with a light that turns green at seven. So we have that, yeah, she would get up, like, you know, super early if she if she could. So she gets up at seven. And then so I have kids from seven to 10, I take care of breakfast, getting them dressed, and then I just kind of keep things picked up so that the house is at least, you know, in put together a little bit, and then my wife gets up around like seven or eight. But then she has time to, like, take a shower and like get breakfast, she can read, she can write, you know, she has achieved as a journal, she does like the bullet journaling. So she plans out today, you know, so like she has time to, like get put together. And that mostly like for our marriage has like been really awesome. Because it's like, it's just it, she's, she feels good. She comes into the day, the kids are already fed, they're kind of in good shape. And she comes down and it's like, okay, it's go time, like, you know, like, let's, you know, then she does school with the kids. And she you know, she takes him out to programs and stuff like that. So like, she has her, you know, a schedule and stuff that she does with them. And then so then that's when I work is like 10, like around 10am I start working. And then I go off at like three, you know, three or four. And then we kind of just tag team for the rest of the evening. So yeah, so I've worked, I actually end up getting, you know, like seven hours of working every day, so but those first two hours are kind of like free time or like personal time. Like if I have a personal project I want to work on or something like that. I'll do it during that time. So yeah,Colleen Schnettler  36:41  that sounds wonderful. So what I'm trying to get out here, Jordan, this is the real question. Were the two to three years of the 12 to 15 hours a day worth it to live the life you're living now.Jordan O'Connor  36:57  Yeah. Oh, yeah. 100%. And I think the interesting thing is, I don't think I would have been able to do it now. It would, it would have been really hard. Right? Like, like, back then, you know, when I first started, we had no kids, but then like, we had one kid. But like, you know, even before they start walking and stuff, they're not really like that much work, you know, it's only when they become toddlers is when Okay, somebody's got to be hands on all the time with at least the kids. Yeah. So. So I had your head, that window of opportunity were like, Okay, I have, you know, I can do this, I can put on a lot of hours. Whereas now, I probably couldn't even put in that many hours without some serious strain on, you know, like the marriage and just like our health and things like that. But yeah, I mean, I think it was worth it, I think, um, you know, you kind of have, you know, those those choices in life, it's like, whether you're going to go for it, and you're going to do the thing, or you're just going to sit back and let life happen to you. And so I was like, Hey, I'm going to I'm going to go for it. I'm going to get control of you know, my finances and control over my time and control over my future. And so I did what I had to do to get there, you know, some people start in a different place, and it's easier for them. So people start in a way worse place, and it's a lot harder for them. So yeah, but yeah, I think I think ultimately, it was worth it for sure.Colleen Schnettler  38:15  So you kind of made a joke earlier, like 30 seconds ago, when I said you're objectively successful. So I have met a lot of people like who are, are making quite a lot of money with their side projects, not side projects with their businesses. And you know, I've talked to people who are making, you know, $50,000 a month who still feel like they need to push, push, push, because it's not good enough. Where do you fall in that spectrum?Jordan O'Connor  38:38  Um, I'm definitely not pushing, I'm not pushing very hard at all. Um, I think, I don't know, I think most of most of my focus right now is on minimizing everything else. So that I can maintain this lifestyle, basically forever, because like, right now, honestly, if anything changed, it would only be for the worse, like, this is kind of like almost as good as it gets. I have like, almost unlimited free time, I get to work on something I want to work on. You know, like my family is well provided for, like, we can kind of schedule our day, however we want it. So those are like, like, there's really no downside. So mostly for me, it's like, okay, like, how can we, you know, get rid of, you know, some of this lingering debt quicker? How can we pay off the house quicker? You know, how can we make sure that you know, like, we're investing and actually growing our wealth, you know, in the background, while we're, you know, in while I'm working so that in the future, you know, if you know, this whole thing blows up, I have, you know, some options and things like that. So, I think for me, that's more of my focus rather than like trying to like, you know, scale closet tools and maximize it and, you know, make a ton of money. You know, I think ultimately, you know, I, I could just go that route and do that. But I think when I have the you know, the three young kids we have a five year old a three year old and One year old. Oh, yeah. Yeah. So, yeah. So like when they're all young, you know, I want to be there with them. Yeah, I think once they get a little older, you know, they can get a little more autonomous, you know, they kind of can entertain themselves, you know, they have things they want to do. And they can go do that. But for now, like, they're super young, like, I don't, you know, I want to be there I want to be hands on. So I don't want to be like, you know, business dad that was never home, you know, like, off doing his thing. You know, I'd rather I'd rather have a balance of like, okay, like, yeah, I make a decent amount of money. But I also get to spend a lot of time with my kids. So like, why would I try to change that balance, you know, to, you know, for the worse, so. So yeah.Colleen Schnettler  40:37  Yeah, that makes that makes total sense. And that's awesome. You're able to do that. Right. I mean, that's, that's amazing. So, yeah,Jordan O'Connor  40:45  that's pretty fortunate.Colleen Schnettler  40:46  Another question I had for you, I either saw this on indie hackers or Twitter, but you had, it was something like never take other people's advice when you are trying to build a business. Do you remember that?Jordan O'Connor  40:57  Um, yeah, I can I can align with that. If I said that. I think you did. It definitely. Sounds like something I would have said. Yeah, I think um, yeah, advice is always so contextual. You know, like, even my advice right now. Like, like I was talking about, like, when, you know, I told my boss, like, Hey, I don't want to be the go to guy. Like, I don't know, if that's the right advice for somebody, maybe that's maybe they need to go hard. You know, maybe they're super lazy, and they need to go harder, or something like that. You know, for me, I was a good employee that wanted to take a little bit of a break, you know, so like, yeah, you know, but you know, so like, you know, people have different, you know, financial situations, they have different family situations that have different health situations, even have different personalities, like I was talking about earlier, where like, some people really want to do like one on one sales, and they really like talking to people and they really like, you know, like, being outgoing and stuff. Like, I don't really like that. So I have to build something totally different. That aligns with me. So like, I run a totally email based business, I don't actually do any calls with anybody. And if you want customer support, you email me like, that's it. Like, I don't have a phone number or anything like that. Yeah. So but for other people, like, you know, they want to be on the phone all day, they want to talk to people, you know, they want to do stuff like that. So, so yeah, I think a lot of a lot of business advice is very, very contextual. And I think until you actually dive in and figure out what works for you, then you're not really going to know what the best advice is, or what advice actually sticks. Because I think, even to a lot of advice, you know, people mean, well, and it does really work for them. But just because it works for them doesn't actually mean it's going to work for you, too. You know, and so like for me early on, like when, when I was taking those courses, you know, a lot of those people were pitching, you know, the the freelancing in the agency style stuff. And so like, I tried it, but like, it didn't work for me, like I was awful at it, like I was terrible at that part of stuff, like I had the great skills, but like dealing with people and like, you know, all that stuff. terrible at it. So like, I was like, I can't make this work, I have to do something different. And so that's how I, you know, got on the, and actually, it was interesting indie hackers launched. I'm trying to think it was about like, a few months before I launched closet tools. It was like, right around that time. So it's actually pretty fortunate because it was cool to, you know, see a group of people kind of doing the same thing that I was wanting to do. You gave me a little bit of confidence to kind of do that. So yeah. But anyways, yeah. So that I think that advice is is I think it most advice is, I don't know, it's mostly worthless. I do think it's interesting to hear people's stories. And as long as they give enough context, like I try to give a lot of context about like, my family, and like, what my financial situation was like, because like, that's the stuff that really matters. Because like, anyway, anybody could be like, oh, yeah, like, learn these skills, and then build a business and you'll make a ton of money. But like, you know, if you don't have the means to actually do that, then how are you? You know, how can you even, you know, attempt to do that? And so yeah, so I think if you can give them enough context, I think some advice can be helpful, or at least helpful enough to where they can be like, Oh, that doesn't even apply to me. You know, like, I you know, like, for me, I see a lot of advice from people that have like, no kids, and they don't like they're not married, they have no kids. And it's like, this doesn't even like you can't do that. Right. Like, I can't do that at all. So yeah, so I think that's important, for sure.Colleen Schnettler  44:18  So what's next for you?Jordan O'Connor  44:21  Um, I don't really know, I'm trying to figure it out. I think, um, I never saw clauses was as a long term thing, but it's sticking around a lot longer than I thought it was actually gonna stick around. So just kind of hanging out there. You know, I still actually I still build and continue to grow with it, you know, I still, you know, add features to it. And I still do marketing and things like that. But I don't know, I think I think I like I enjoy writing a lot. So I would like to do some sort of writing thing. I am writing a, an SEO sales book called rank to sell. So I'm working on that. Not that I think that that's going to be like my full time thing like Oh, I'm an author now. Because I think, you know, my code is pretty valuable, too. So, um, so yeah, I mean, some kind of hybrid of writing and code. In the future. I'm definitely on board with building more simple SAS products I have no, you know, I would like to do that, even in the same niche, you know, I can serve the same customer set with some different types of tools. And so, there's a lot of different platforms that these retailers sell on. So. So yeah, I mean, honestly, it's just kind of iterative stuff. It's not like anything like, oh, you know, I'm, you know, switching my whole life over to like something else. It's mostly like, hey, like, I'm here. How can I, you know, how can I invest a little more? How can I, you know, add a little more, you know, financial stability, a little more income, or, you know, another product or something, just something a little bit more iterative. And just kind of, like, keep the thing going, basically, it's kind of that's, that's mostly what it is. So, I've been thinking a lot lately about, like, some kind of business that I can get my kids involved in, but I haven't really come up with anything yet. I think it would be super cool to like, have them, you know, work on something with me, but I don't know. That's, that's honestly, that's kind of the dream for me is like, that would be cool. You know, but I don't know. I don't know what that is yet.Colleen Schnettler  46:09  Yeah, that would be cool. Wonderful. Well, Jordan, thank you so much for coming on today and sharing your story with us. And, you know, teaching us about some of the things that helped you grow closet tools. I really appreciate having you.Jordan O'Connor  46:26  Yeah, sure. Yeah. Thanks for having me. It was a lot of fun.Colleen Schnettler  46:29  And that will wrap up this week's episode of the software social podcast. Thank you so much for listening. You can find us on Twitter at software social pod

No Plans to Merge
Max is not well-liked at school

No Plans to Merge

Play Episode Listen Later Nov 29, 2021 129:35


Max is a misunderstood good boy. Where is Daniel's passport? React. Dom. Collections just feel heavy....

Release Notes
#445: Not JavaScript

Release Notes

Play Episode Listen Later Nov 29, 2021 31:49


Today Charles takes his turn on the couch and talks to Joe about some problems he's been dealing with. We talk about a feature update that has taken much longer than expected, how to push a contractor to make more progress, and a newly discovered issue with Charles' e-signature tool that could be catastrophic if […]

Maintainable
Shaundai Person: Work on Having a Short-term Memory

Maintainable

Play Episode Listen Later Nov 29, 2021 51:23


Robby speaks with Shaundai Person, Senior Software Engineer at Netflix and creator of TypeScript for JavaScript devs. In this episode, Shaundai shares her experience of moving from a career in sales to software engineering, traits of maintainable software, and how to make an impact when you join a new team.Helpful LinksShaundai's TwitterShaundai's LinkedInShaundai's PolyworkTypeScript for JavaScript Developers, that Shaundai is building.Talk: Simple Made Easy by Rich HickeyBook Recommendation: Range: Why Generalists Triumph in a Specialized world by David EpsteinSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

Talking Kotlin
Moving 1M users to Kotlin & Compose: JB Toolbox

Talking Kotlin

Play Episode Listen Later Nov 28, 2021 45:03


Victor Kropp tells us the story of moving JetBrains Toolbox from C++ to 100% Kotlin. Victor (https://twitter.com/kropp) leads the Toolbox team at JetBrains, a small app that is the single entry point for developing with JetBrains IDEs, which you can download at https://www.jetbrains.com/toolbox-app/. It allows you to automatically download and update your IDEs, and open all your projects with a single click. Victor shares the story of how toolbox came to be – from its humble beginnings as an internal Hackathon project back in 2015, to an app serving 1 million monthly active users. Together, we dive into the tech stack of Toolbox and its evolution. We learn about the initial tech stack: C++ for the business logic and JavaScript and React for the user interface. Victor shares the challenges and benefits of using this stack – from hiring to UI visuals. We learn why Toolbox took the big step of migrating from C++ to Kotlin, from the ability to reuse code in the IntelliJ platform to developer ergonomics. Victor takes us through the multi-step process of how they arrived at a pure-Kotlin solution. The first step we talk about is the migration of the Toolbox business logic to Kotlin using Regex wizardry and reimplementing methods with the help of Kotlin's auto-converter. Victor then sheds some light on replacing the embedded web user interface with Compose for Desktop (https://www.jetbrains.com/lp/compose/), and the benefits Toolbox gained from it: reducing the load of having to serialize a lot of objects, being able to use the same language when implementing a full feature front to back, library reuse, and better performance. We learn that this transition only took 6 months, while still being able to ship new features to Toolbox at the same time, and why the team chose Kotlin on the JVM instead of Kotlin/Native. With React and Compose for Desktop both being modern declarative UI frameworks, Victor also talks more about how concepts and vocabulary transfers between the two (https://tigeroakes.com/posts/react-to...), lowering the barrier of entry for people who want to build native user interfaces and already have web development experience. We also learn more about how Toolbox moved design primitives and UI components from the CSS to the Compose layout system, among other topics. Seb also compliments Hadi on the Ktor 2.0 presentation (https://www.youtube.com/watch?v=mye9N...) from the Kotlin 2021 Premier Online Event (https://pages.jetbrains.com/kotlin-pr...).

Chit Chat Across the Pond
CCATP #706 – Bart Busschots on PBS 130 of X – Good Technical Documentation

Chit Chat Across the Pond

Play Episode Listen Later Nov 28, 2021 71:20


As we embark on our journey to create a JavaScript module for the strong, memorable password generating service XKPASSWD, Bart explains the importance of creating good documentation. That sounds super annoying and tedious, and it is, so Bart explains why a good documentation generator will be our friend. He outlines the two distinctly different users of our documentation: those of us who will be helping to create the code itself as part of the community project, but also for the people who will be users of our JavaScript module. Those users will be interested in how to take the module and embed it into a web page to generate passwords, or to create an Alfred scheme and more. These two different users will have different requirements, and yet our documentation generator can fill both needs without unnecessary extra work. This isn't the sexiest topic, but Bart does convince me that the tools will help us to have the rigor to do it and not let our human instincts take over and allow our documentation to get out of date. You can find Bart's fabulous shownotes at pbs.bartificer.net

Programming By Stealth
PBS 130 of X – Good Technical Documentation

Programming By Stealth

Play Episode Listen Later Nov 28, 2021 71:20


As we embark on our journey to create a JavaScript module for the strong, memorable password generating service XKPASSWD, Bart explains the importance of creating good documentation. That sounds super annoying and tedious, and it is, so Bart explains why a good documentation generator will be our friend. He outlines the two distinctly different users of our documentation: those of us who will be helping to create the code itself as part of the community project, but also for the people who will be users of our JavaScript module. Those users will be interested in how to take the module and embed it into a web page to generate passwords, or to create an Alfred scheme and more. These two different users will have different requirements, and yet our documentation generator can fill both needs without unnecessary extra work. This isn't the sexiest topic, but Bart does convince me that the tools will help us to have the rigor to do it and not let our human instincts take over and allow our documentation to get out of date. You can find Bart's fabulous shownotes at pbs.bartificer.net

Changelog Master Feed
From engineering to product (JS Party #203)

Changelog Master Feed

Play Episode Listen Later Nov 26, 2021 65:36


Liana Leahy tells Amal and KBall all about her journey from software engineer to product manager. Along the way we learn what a PM does, how to be great at it, how to know if it's for you, why the role is in such demand these days, and much more. - It's UNIX, I know this!

PodRocket - A web development podcast from LogRocket
Blitz.js with Brandon Bayer (Repeat)

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Nov 26, 2021 22:16


Originally published on January 12, 2021 We are taking this week off from production. We will be back with new episodes on November 30th. Ben and Brian talk to Brandon Bayer, creator of Blitz.js. We take a deep dive into everything Blitz has to offer. More specifically, we address how Blitz compares with other fullstack frameworks and how Blitz balances being opinionated with being flexible for each aspect of the toolchain. We also talk about community building and beyond. Links https://github.com/blitz-js/blitz/wiki https://blitzjs.slack.com https://blitzjs.com/docs/contributing https://blitzjs.com https://twitter.com/flybayer https://twitter.com/blitz_js https://blog.logrocket.com/introduction-to-blitz-js https://blog.logrocket.com/building-a-fullstack-react-application-with-blitz-js Contact us https://podrocket.logrocket.com/contact-us @PodRocketpod (https://twitter.com/PodRocketpod) What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Brandon Bayer.

React Native Radio
RNR 219 - React Native 0.66

React Native Radio

Play Episode Listen Later Nov 24, 2021 25:57


In this episode, Jamon, Mazen, and Jon Major talk about what's new with React Native 0.66, and…Sweatcoin?This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.Helpful Links:Full changelogPicker (deprecated)Check out this free app — It Pays to Walk

Greater Than Code
260: Fixing Broken Tech Interviews with Ian Douglas

Greater Than Code

Play Episode Listen Later Nov 24, 2021 64:32


01:01 - Ian's Superpower: Curiosity & Life-Long Learning * Discovering Computers * Sharing Knowledge 06:27 - Streaming and Mentorship: Becoming “The Career Development Guy” * The Turing School of Software and Design (https://turing.edu/) * techinterview.guide (https://techinterview.guide/) * twitch.tv/iandouglas736 (https://www.twitch.tv/iandouglas736) 12:01 - Tech Interviews (Are Broken) * techinterview.guide (https://techinterview.guide/) * Daily Email Series (https://techinterview.guide/daily-email-series/) * Tech vs Behavior Questions 16:43 - How do I even get a first job in the tech industry? * Tech Careers = Like Choose Your Own Adventure Book * Highlight What You Have: YOU ARE * Apply Anyway 24:25 - Interview Processes Don't Align with Skills Needed * FAANG Company (https://en.wikipedia.org/wiki/Big_Tech) Influence * LeetCode-Style Interviews (https://leetcode.com/explore/interview/card/top-interview-questions-medium/) * Dynamic Programing Problems (https://medium.com/techie-delight/top-10-dynamic-programming-problems-5da486eeb360) * People Can Learn 35:06 - Fixing Tech Interviews: Overhauling the Process * Idea: “Open Source Hiring Manifesto” Initiative * Analyzing Interviewing Experiences; Collect Antipatterns * Community/Candidate Input * Company Feedback (Stop Ghosting! Build Trust!) * Language Mapping Reflections: Mandy: Peoples' tech journeys are like a Choose Your Own Adventure book. Keep acquiring skills over life-long learning. Arty: The importance of 1-on-1 genuine connections. Real change happens in the context of a relationship. Ian: Having these discussions, collaborating, and saying, “what if?” This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: ARTY: Hi, everyone. Welcome to Episode 260 of Greater Than Code. I am Arty Starr and I'm here with my fabulous co-host, Mandy Moore. MANDY: Thank you, Arty. And I'm here with our guest today, Ian Douglas. Ian has been in the tech industry for over 25 years and suggested we cue the Jurassic Park theme song for his introduction. Much of his career has been spent in early startups planning out architecture and helping everywhere and anywhere like a “Swiss army knife” engineer. He's currently livestreaming twice a week around the topic of tech industry interview preparation, and loves being involved in developer education. Welcome to the show, Ian. IAN: Thanks for having me. It's great to be here. MANDY: Awesome. So we like to start the show with our famous question: what is your superpower and how did you acquire it? IAN: Probably curiosity. I've always been kind of a very curious mindset of wanting to know how things work. Even as a little kid, I would tear things apart just to see how something worked. My parents would be like, “Okay, great. Put it back together.” I'm like, “I don't know how to put it back together.” So [chuckles] they would come home and I would just have stuff disassembled all over the house and yeah, we threw a lot of stuff out that way. But it was just a curiosity of how things work around me and that led into computer programming, learning how computers worked and that just made the light bulb go off in my mind as a little kid of, I get to tell this computer how to do something, it's always going to do it. And that just led of course, into the tech industry where you sign up for a career in the tech industry, you're signing up for lifelong learning and there's no shortage of trying to satiate that curiosity. I think it's just a never-ending journey, which is fantastic. ARTY: When did you first discover computers? What was that experience like for you? IAN: I was 8 years old. I think it was summer, or fall of 1982. I believe my dad came home with a Commodore 64. My dad was always kind of a gadget nut. Anything new and interesting on the market, he would find an excuse to buy and so he, brought home this Commodore 64 thinking family computer, but once he plunked it down in front of me, it sort of became mine. I didn't want to share. I grew up in Northern Canada way, way up in the Northwest territories and in the wintertime, we had two things to do. We could go play hockey, or we'd stay indoors and not freeze. So I spent a lot of time indoors when I wasn't playing hockey—played a lot of hockey as a kid. But when I was home, I was basically on this Commodore 64 all the time, playing games and learning how the computer itself worked and learning how the programming language of it worked. Thankfully, the computer was something I had never took apart. Otherwise, it would have been a pile of junk, but just spending a lot of time just learning all the ins and outs. Back then, the idea was you could load the software and then you type a run command and it would actually execute the program. But if you type a list, it would actually show you all the source code of the program as well and that raised my curiosity, like what is all this symbols and what all these words mean? In the back of the Commodore 64 book, it had several chapters about the basic programming language. So I started picking apart all these games and trying to learn how they worked and then well, what would happen if I change this instruction to that and started learning how to sort of hack my games, usually break the game completely. But trying to hack it a little bit; what if I got like an extra ship, an extra level, or what if I change the health of my character, or something along those lines? And it kind of snowballed from there, honestly. It was just this fascination of, oh, cool, I get to look at this thing. I get to change it. I get to apply it. And then of course, back in the day, you would go to a bookstore and you'd have these magazines with just pages and pages and pages of source code and you'd go home and you type it all in expecting something really cool. At the end of it, you run it and it's something bland like, oh, you just made a spreadsheet application. It's like, “Oh, I wanted a game.” Like, “Shucks.” [laughter] But as a little kid, that kind of thing wasn't very enticing, but I'm sure as an adult, it's like, oh cool, now I have a spreadsheet to track budgeting, or whatever at home. It was this whole notion of open source and just sharing knowledge and that really stuck with me, too and so, as I would try to satiate this innate curiosity in myself and learn something, I would go teach it to a friend and it's like, “Hey, hey, let me show you what I just did. I learned how to play this thing on the piano,” or “I learned how to sing this song,” or “I learned how to use a magnifying glass to cook an ant on the sidewalk.” [chuckles] Whatever I learned, I always wanted to turn around and teach it to somebody else. I would get sometimes more excitement and joy out of watching somebody else do it because I taught them than the fact that I was able to learn that and do it myself. And so, after a while it was working on the computer became kind of a, oh yeah, okay, I can work on the computer, I can do the thing. But if I could turn around and show somebody else how to do that and then watch them explore and you watch that light bulb go off over their head, then it's like, oh, they're going to go do something cool with that. Just the anticipation of how are they going to go use that knowledge, that really stuck with me my whole life. In high school doing little bits of tutoring here and there. I was a paid tutor in college. Once I got out of college and got into the workplace, again, just learning on my own and then turning around and teaching others led into running my own web development business where I was teaching some friends how to do web development because I was taking on so much work that I had to subcontract it the somebody where I wasn't going to meet deadlines and so, I subcontracted them. That meant that I got to pay my friends to help me work this business. And so, that kind of kicked off and then I started learning well, how to servers work and how does the internet work and how do I run an email server on all this stuff? So just never-ending stream of knowledge going on in the internet and then just turning around and sharing that knowledge and keeping that community side of things building up over time. MANDY: Very cool. So in your bio, it said you're streaming now so I'm guessing that's a big part of what you do today with the streaming. So what are you streaming? IAN: So let's see, back in 2014, I started getting involved in mentorship with a local code school here in Denver called The Turing School of Software and Design. It's the 7-month code program and they were looking for someone that could help just mentor students. They were teaching Ruby on Rails at the time. So I got involved with them. I was working in Ruby at SendGrid at the time where I was working, who was later acquired by Twilio. And I'm like, “Yeah, I got some extra time. I can help some people out.” I like giving back and I like the idea of tutoring and teaching. I started that mentorship and it quickly turned into hey, do any of our mentors know anything about resumes and the hiring and interviewing and things like that. And by that point, I had been the lead engineer. I had done hiring. I hired several dozen engineers at SendGrid, or helped hire several dozen people at SendGrid. And I'm like, “Yeah, I've looked at hundreds and thousands of resumes.” Like, “What can I help with?” So I quickly became the career development guy to help them out and over time, the school started developing their career development curriculum and I like to think I had a hand in developing some of that. 3 years later, they're like, “You just want a job here? Like you're helping so many students, you just want to come on staff?” And so, I joined them as an instructor, taught the backend program, had a blast, did that for almost 4 full years. And then when I left Turing in June of 2021, I thought, “Well, I still want to be able to share this knowledge,” and so, I took all these notes that I had been writing and I basically put it all onto a website called techinterview.guide. When I finished teaching, I'm like, “Well, I still miss sharing that knowledge with people,” and I thought, “How else can I get that knowledge out there in a way that is scalable and manageable by one human being?” And I thought, “Well, I'll just kind of see what other people are doing.” Fumbled around on YouTube, watched some YouTube videos, watched people doing livestreaming on LinkedIn, livestreaming on Facebook, livestreaming on YouTube and trying to think could I do that? Nah, I don't know if I could do that. A friend of mine named Jonan Scheffler, he currently works at New Relic, he does a live stream. So I was hanging out on his stream one night and it was just so much fun seeing people interact and chat and how they engage the people in the chat and answering questions for them. I'm like, “I wonder if I could do that.” The curiosity took over from there and you can imagine where that went; went way down some rabbit holes on how to set up a streaming computer. Started streaming and found out that I wasn't very good at audio routing, [chuckles] recording things, and marketing, all that kind of stuff. But I kind of fumbled my way through it and Jonan was very generous with his time to help me straighten some things out and it kind of took off from there. So I thought, “Well, now I've got a platform where I can share this career development advice having been in the industry now for 25 years. Now, I've been director of engineering. I'm currently the director of engineering learning at a company. I've got an education background now as an instructor for several years. I've been doing tons of mentoring.” I love to give back and I love to help other people learn a thing that's going to help improve their life. I think of it like a ripple effect, like I'm not going to go out and change the world, but I can change your world and that ripple effect is going to change somebody else's world and that's going to change somebody else's world. So that's how I see my part in all of this play out. I'm not looking to be the biggest name in anything. I'm just one person with a voice and I'm happy to share my ideas and my perspectives, but I'm also happy to have people on my stream that can share their ideas and perspectives as well. I think it's important to hear a lot of perspectives, especially when it comes to things like job hunt, interview prep, and how to build a resume. You're going to see so much conflicting advice out there like, “This is the way you should do it,” and someone else will be like, “No, this is the way you should do it.” Meanwhile, I'm on the sidelines going, “You can do it all of that way.” Just listen to everybody's advice and figure out how you want to build your resume and then that's your resume. It doesn't have to look like the way I want it, or the way that someone else wants it; it can look how you want it to look. This is just our advice kind of collectively. So the livestream took off from there and I've got only a couple of hundred followers, or so on Twitch, but it's been a lot of fun just engaging with chat and people are submitting questions to me all the time. So I do a lot of Q&A sessions, like ask me anything sessions and it's just been a ton of fun. ARTY: That's awesome. I love the idea of focusing on one person and how you can make a difference in that one person's life and how those differences can ripple outward. That one-on-one connection, I feel like if we try and just broadcast and forget about the individuals, it's easy for the message and stuff to just get lost in ether waves and not actually make that connection with one person. Ultimately, it's all those ones that add up to the many. IAN: Definitely. Yeah. ARTY: So can you tell us a little bit more about the Tech Interview Guide and what your philosophy is regarding tech interviews? IAN: The tech interview process in – well, I mean, just the interview process in general in the tech industry is pretty broken. It lends itself very well to people who come from position and privilege that they can afford expensive universities and have oodles and oodles of free time to go study algorithms for months and months and months to go jump through a whole bunch of hoops for companies that want four, or five, six rounds of interviews to try to determine whether you're the right fit for the company and it's super broken. There are a lot of companies out there that are trying to change things a little bit and I applaud them. It's going to be a tough journey, for sure. Trying to convince companies like hey, this is not working out well for us as candidates trying to apply for jobs. As a company, though I understand because I've been a hiring manager that you need to be able to trust the people that you're hiring. You need to trust that they can actually do the job. Unfortunately, a lot of the tech interview process does not adequately mimic what the day-to-day responsibility of that job is going to be. So the whole philosophy of me doing the Tech Interview Guide is just an education of, “Hey, here's my perspective on what you're likely to face as a technical interview. These are the different stages that you'll typically see.” I have a lot of notes on there about how to build a resume, how to build a cover letter, thoughts on building a really big resume and then how to trim it down to one page to go apply for a particular job. How to write a cover letter that's customized to the business to really position yourself as the best candidate for that role. And then some chapters that I have yet to write are going to be things like how do you negotiate once you get an offer, like what are some negotiation tips. I've shared some of them live on the stream and I've shared a growing amount of information as I learn from other people as well, then I'll turn around and I'll share that on the stream. The content that's actually on the website right now is probably 3, 4 years old, some of it at least and so, I'm constantly going back in and I'm trying to revamp that material a little bit to kind of be as modern as possible. I used to want to go a self-publish route where I actually made a book. Several of my friends have actually gone through the process of actually making a book and getting it published. I'm like, “Oh, I want to do that, too. My friends are doing that. I could do that, too,” and I got looking into it. It's like, okay, it's an expensive, really time-consuming process and by the time I get that book on a shelf somewhere, a lot of the information is going to be out of date because a lot of things in the tech industry change all the time. So I decided I would just self-publish an online book where I can just go in and I can just constantly refresh the information and people can go find whatever my current perspective is by going to the website. And then as part of the website, I also have a daily email series that people can sign up for. I'm about to split it into four mailing lists. But right now, it's a single mailing list where I'm presenting technical questions and behavioral questions that you're likely to get asked as a web developer getting into the business. But I don't spend time in the email telling you how to answer the question; what I do instead is I share from the interviewer's perspective. This is why I'm asking you this question. This is what I hope to hear. This is what's important for me to hear in your answer. Because there's so many resources out there already that are trying to tell you how to craft the perfect answer, where I'm trying to explain this is why this question is important to us in the first place. So I'm taking a little bit different perspective on how I present that information and to date I've sent out, I don't know, something like 80,000 emails over a couple of years to folks that have signed up for that, which has been really tremendous to see. I get a lot of good feedback from that. But again, that information it doesn't always age well and interview processes change. I'm actually going through the process right now in the month of November to rewrite a lot of that information, but then also break out into multiple lists and so, where right now it's kind of a combination of a little bit of technical questions, a little bit of behavioral questions, a little bit of procedural, like what is an interview and so on. Now I'm actually going to break them out into separate lists of this list is all just technical questions and this list is all just behavioral questions and this list is going to be general process and then the process of going through the interview and how to do research and so on. And then the last one is just general questions and answers and a lot of that is stemmed from the questions that people have submitted to me that I answered on the live stream. So it all kind of packages up together. MANDY: That's really cool. I'd like to get into some of the meat of the material that you're putting out here. IAN: Yeah. MANDY: So as far as what are some of the biggest questions that you get on your street? IAN: Probably the most popular question I get—because a lot of the people that come by the stream and find the daily email list are new in the industry and they're trying to find that first job. And so by far, the number one question is, how do I even get a job in the industry right now? I have no experience. I've got some amount of education, whether it's an actual CS degree, or something similar to a CS degree, or they've gone through a bootcamp of some kind. How do I even get that first job? How do I position myself? How do I differentiate myself? How do I even get a phone call from a company? That's a lot of what's broken in the industry. Everybody in the industry right now wants people with experience, or they're saying like, “Oh, this is a “entry-level role,” but you must have 3 to 4 years' experience.” It's like, well, it's not entry level if you're asking for experience; it can't be both. All they're really doing is they're calling it an entry-level role so they don't have to pay you as much. But if they want 3-, or 4-years' experience, then you should be paying somebody who has 3-, or 4-years' experience. So the people writing these job posts are off their rocker a little bit, but that's by far, the number one question I get is how do I even get that first job. Once you get that first job and you get a year, year and a half, 2 years' experience, it's much easier to get that second job, or third job. It's not like oh, I'm going to quit my job today and have a new job tomorrow. But the time to get that next job is usually much, much shorter than getting this first job. I know people that have gone months and months, or nearly a year just constantly trying to apply, getting ghosted, like not getting any contact whatsoever from companies where they're sending in resumes and trying to apply for these jobs. Again, it's just a big indication of what's really broken in our industry that I think could be improved. I think that there's a lot of room for improvement there. MANDY: So what do you tell them? What's your answer for that? How do they get their first job? How do you get your first job? IAN: That's a [chuckles] good question. And I hate to fall back on the it depends answer. It really does depend on the kind of career that you want to have. I tell people often in my coaching that the tech industry is really a choose your own adventure kind of book. Like, once you get that job a little bit better, what you want your next job to be and so, you get to choose. If you get your first job as a QA developer, or you get that first job as a technical writer, or you get that first job doing software development, or you get that first job in dev ops and then decide, you don't want to do that anymore, that's fine. You can position yourself to go get a job doing some other kind of technical job that doesn't have to be what your previous job was. Now, once you have that experience, though recruiters are going to be calling you and saying, “Hey, you had a QA role. I've also got a QA role,” and you just have to stand firm and say, “No, that's not the direction I'm taking my career anymore. I want to head in this direction. So I'm going to apply for a company where they're looking for people with that kind of direction.” It really comes down to how do you show the company what you bring to the company and how you're going to make the company better, how are you going to make the team better, what skill, experience, and background are you bringing to that job. A lot of people, when they apply for the job, they talk about what they don't have. Like, “Oh, I'm an entry level developer,” or “I only went to a bootcamp,” or “I don't know very much about some aspect of development like I don't know, test driven development,” or “I don't really understand object-oriented programming,” or “I don't know anything about Docker, but I want to apply for this job.” Well, now you're highlighting what you don't have and to get that first job, you have to highlight what you do have. So I often tell people on your resume, on your LinkedIn, don't call yourself a junior developer. Don't call yourself an entry level. Don't say you're aspiring to be. You are. You are a developer. If you have studied software development, you can write software, you're a software developer. Make that your own title and let the company figure out what level you are. So just call yourself a developer and start applying for those jobs. The other advice that I tend to give people is you don't have to feel like you meet a 100% of the requirements in any job posts. As a hiring manager, when I read those job posts often, it's like, this is my birthday wish list. I hope I can find this mythical unicorn that has all of these traits [laughter] and skills and characteristics and that person doesn't exist. In fact, if I ever got a resume where they claim to have all that stuff, I would immediately probably throw the resume in the bin because they're probably lying, because either they have all those skills and they're about to hit me up for double the salary, or they're just straight up lying that they really don't have all those skills. As a hiring manager, those are things that we have to discern over time as we're evaluating people and talking with them and so on. But I would say if you meet like 30 to 40% of those skills, you could probably still apply. The challenge then is when you get that phone call, how do you convince them that you're worth taking a shot, that you're worth them taking the risk of hiring you, helping train you up in the skills that you don't have. But on those calls, you still need to present this is what I do bring to the company. I'm bringing energy, I'm bringing passion, and I'm bringing other experience and background and perspectives on things, hopefully from – just increasing the diversity in tech, just as an example. You're coming from a background, or a walk of life that maybe we don't currently have on the team and that's great for us and great for our team because you're going to open our eyes to things that we might not have thought of. So I think apply anyway. If they're asking for a couple of years' experience and you don't have it, apply anyway. If they're asking for programming languages you don't know, apply anyway. The languages you do know, a lot of that skill is going to transfer into a new language anyway. And I think a lot of companies are really missing out on the malleability and how they can shape an entry-level developer into the kind of developer and kind of engineer that they want to have on the team. Now you use that person as an example and say, “Now we've trained them with the process that we want, with the language and the tools that we want. They know the company goals.” We've trained them. We've built them up. We've invested in them and now everybody else we hire, we're going to hold to that standard and say, “If we're going to hire from outside, this is what we want,” and if we hire someone who doesn't have that level of skill, we're going to bring them up to that skill. I think a lot of companies are missing out on that whole aspect of hiring, that is they can take a chance on somebody who's got the people skills and the collaboration skills and that background and the experiences of life and not necessarily the technical skills and just train them on the technical skills. I went on a rant on this on LinkedIn the other day, where I was saying the return on investment. If a company is spending months and months and months trying to hire somebody, that's expensive. You're paying a recruiter, you're paying engineers, you're paying managers to screen all these people, interview all these people, and you're not quite finding that 100% skill match. Well, what if you just hired somebody months ago, spend $5,000 training them on the skills they didn't have, and now you're months ahead of the game. You could have saved yourself so much money so much time. You would have had an engineer on the team now. And I think a lot of companies are kind of missing that point. Sorry, I know I get very soapbox-y on some of the stuff. ARTY: I think it's important just highlighting these dynamics and stuff that are broken in our industry and all of the hoops and challenges that come with trying to get a job. You mentioned a couple of things on the other side of one, is that the interview processes themselves don't align to what it is we actually need skill-wise day-to-day. What are the things that you think are driving the creation of interviews that don't align with the day-to-day stuff? Like what factors are bringing those things so far out of alignment? IAN: That's a great question. I would say I have my suspicions. So don't take this as gospel truth, but from my own perspective, this is what I think. The big, big tech companies out there, like the big FAANG companies, they have a very specific target in mind of the kind of engineers that they want on their team. They have studied very deep data structures and algorithms, the systems thinking and the system design, and all this stuff. Like, they've got that knowledge, they've got that background because those big companies need that level of knowledge for things like scaling to billions of users, highly performant, and resilient systems. Where the typical startup and typical small and mid-sized company, they don't typically need that. But those kinds of companies look at FAANG companies and go, “We want to be like them. Therefore, we must interview like them and we must ask the same questions that they ask.” I think this has this cascading effect where when FAANG companies do interviews in a particular way, we see that again, with this ripple effect idea and we see that ripple down in the industry. Back in the early 2000s, mid 2000s—well, I guess right around the time when Google was getting started—they were asking a lot of really oddball kinds of questions. Like how many golf balls fit in a school bus and those were their interview challenges. It's like, how do you actually go through the calculation of how many golf balls would fit in a school bus and after a while, I think by 2009, they published an article saying, “Yeah, we're going to stop asking those questions. We weren't getting good signals. Everybody's breaking down those problems the same way and it wasn't really helpful.” Well, leading up to that point, everyone else was like, “Oh, those are cool questions. We're going to ask those questions, too,” and then when Google published that paper, everyone else was like, “Yeah, those questions are dumb. We're not going to ask those questions either.” And then they started getting into what we now see as like the LeetCode, HackerRank type of technical challenges being asked within interviews. I think that there's a time and place for some of that, but I think that the types of challenges that they're asking candidates to do should still be aligned with what the company does. One criticism that I've got. For example, I was looking at a technical challenge from one particular company that they asked this one particular problem and it was using a data structure called Heap. It was, find a quantity of location points closest to a target. So you're given a list of latitude, longitude values, and you have to find the five latitude and longitude points that are closest to a target. It's like, okay and so, I'm thinking through the challenge, how would I solve that if I had to solve it? But then I got thinking that company has nothing to do with latitude and longitude. That company has nothing to do with geospatial work of any kind. Why are they even asking that problem? Like, it's so completely misaligned that anybody they interview, that's the first thing that's going to go through their mind as a candidate is like, “Why are they asking me this kind of question?” Like, “This has nothing to do with the job. It had nothing to do with the role. I don't study global positioning and things like that. I know what latitude and longitude are, but I've never done any kind of math to try to figure out what those things would be and how you would detect differences between them.” Like, I could kind of guess with simple math, but unless you've studied that stuff, it's not going to be this, “Oh yeah, sure, no problem. It's this formula, whatever.” We shouldn't have to expect that candidates coming to a business are going to have that a, formula memorized, especially when that's not what your company does. And a lot of companies are like, “Oh, we're got to interview somebody. Quick, go to LeetCode and find a problem to ask them.” All you're going to do is you're going to bias your interview process towards people that have studied those problems on LeetCode and you're not actually going to find people that can actually solve your day-to-day challenges that your company is actually facing. ARTY: And instead, you're selecting for people that are really good at things that you don't even need. [chuckles] It's like, all right! It totally skews who you end up hiring toward people that aren't even necessarily competent in the skills that they actually need day-to-day. Like you mentioned FAANG companies need these particular skills. I don't even think that for resilience, to be able to build these sort of systems, and even on super hardcore systems, it's very seldom that you end up writing algorithmic type code. Usually, most of the things that you deal with in scaling and working with other humans and stuff, it's a function of design and being able to organize things in conceptual ways that make sense so that you can deconstruct a complex, fuzzy problem into little pieces that make sense and can fit together like a jigsaw puzzle. I have a very visual geometric way of thinking, which I find actually is a core ability that makes me good at code because I can imagine it visually laid out and think about the dependencies between things as like tensors between geographically located little code bubbles, if you will. IAN: Sure. ARTY: Being able to think that way, it's fundamentally different than solving algorithm stuff. But that deconstruction capability of just problem breakdown, being able to break down problems, being able to organize things in ways that make sense, being able to communicate those concepts and come up with abstractions that are easy enough for other people on your team to understand, ideally, those are the kinds of engineers we want on the teams. Our interview processes ought to select for those day-to-day skills of things that are the common bread and butter. [chuckles] IAN: I agree. ARTY: What we need to succeed on a day-to-day basis. IAN: Yeah. We need the people skills more than we need the hard technical skills sometimes. I think if our interview process could somehow tap into that and focus more on how do you collaborate, how do you do code reviews, how do you evaluate someone else's code for quality, how do you make the tradeoff between readability and optimization—because those are typically very polarized, opposite ends of the scale—how do you function on a team, or do you prefer to go heads down and just kind of be by yourself and just tackle tasks on your own? I believe that there's a time and place for that, too and there are personality types where you prefer to go heads down and just have peace and quiet and just get your work done and there's nothing wrong with that. But I think if we can somehow tap into the collaborative process as part of the interview, I think it's going to open a lot of companies up to like, “Oh, this person's actually going to be a really great team member. They don't quite have this level of knowledge in database systems that we hope they'd have, but that's fine. We'll just send them on this one-week database training class that happens in a week, or two and now they'll be trained.” [overtalk] MANDY: Do they want to learn? IAN: Right. Do they want to learn? Are they eager to learn? Because if they don't want to learn, then that's a whole other thing, too. But again, that's something that you can screen for. Like, “Tell me what you're learning on the side, or “What kinds of concepts do you want to learn?” Or “In this role, we need you to learn this thing. Is that even of interest to you?” Of course, everyone's going to lie and say, “Yeah,” because they want the paycheck. But I think you can still narrow it down a little bit more what area of training does this person need. So we can just hire good people on the team and now our team is full of good people and collaborative, team-based folks that are willing to work together to solve problems together and then worry about the technical skills as a secondary thing. MANDY: Yeah. I firmly believe anybody can learn anything, if they want to. I mean, that's how I've gotten here. IAN: Yeah, for sure. Same with me. I'm mostly self-taught. I studied computer engineering in college, so I can tell you how all the little microchips in your computer work. I did that for the first 4 years of my career and then I threw all that out the window and I taught myself web development and taught myself how the internet works. And then every job I had, that innate curiosity in me is like, “Oh, I wonder how e-commerce works.” Well, I went and got an e-commerce job, it's like, okay, well now I wonder how education works and I got into the education sector. Now, I wonder how you know this, or that works and so, I got into financial systems and I got into whatever and it just kind of blew my mind. I was like, “Wow, this is how all these things kind of talk to each other,” and that for me was just fascinating, and then turning around and sharing that knowledge with other people. But some people are just very fixed mindset and they want to learn one thing, they want to do that thing, and that's all they know. But I think, like we kind of talked about early in the podcast, you sign up for a career in this industry and you're signing up for lifelong learning. There's no shortage to things that you can go learn, but you have to be willing to do it. MID-ROLL: Rarely does a day pass where a ransomware attack, data breach, or state sponsored espionage hits the news. It's hard to keep up with all this and also to know if you're protected. Don't worry, Kaspersky's got you covered. Each week their team looks at the latest news, stories, and topics you might have missed during the week on the Transatlantic Cable Podcast. Mixing in-depth discussion, expert guests from around the world, a pinch of humor, and all with an easy to consume style - be sure you check them out today. ARTY: What kind of things could we do to potentially influence the way hiring is done and these practices with unicorn skilled searches and just the dysfunctional aspects on the hiring side? Because you're teaching all these tech interview skills for what to expect in the system and how to navigate that and succeed, even though it's broken. But what can we do to influence the broken itself and help improve these things? IAN: That's a great question. Breaking it from the inside out is a good start. I think if we can collectively get enough people together within these, especially the bigger companies and say like, “Hey, collectively, as an industry, we need to do interviewing differently.” And then again, see that ripple effect of oh, well, the FAANG companies are doing it that way so we're going to do it that way, too. But I don't think that's going to be a fast change by any stretch. I think there are always going to be some types of roles where you do have to have a very dedicated, very deep knowledge of system internals and how to optimize things, and pure algorithmic types of thinking. I think those kinds of jobs are always going to be out there and so, there's no fully getting away from something like a LeetCode challenge style interview. But I think that for a lot of small, mid-sized, even some large-sized companies, they don't have to do interviewing that way. But I think we can all stand on our soapbox and yell and scream, “Do it differently, do it differently,” and it's not going to make any impact at all because those companies are watching other companies for how they're doing it. So I think gradually, over time, we can just start to do things differently within our own company. And I think for example, if the company that I was working at, if we completely overhauled our interview process that even if we don't hire somebody, if someone can walk away from that going, “Wow, that was a cool interview experience. I've got to tell my friends about this.” That's the experience that we want when you walk away from the company if we don't end up hiring. If we hire you, it's great. But even if we don't hire you, I want to make sure that you've still got a really cool interview experience that you enjoyed the process, that it didn't just feel like another, “Okay, well, I could have just grind on LeetCode for three months to get through that interview.” I don't ever want my interviews to feel like that. So I think as more of us come to this understanding of it's okay to do it differently and then collectively start talking about how could we do it differently—and there are companies out there that are doing it differently, by the way. I'm not saying everyone in the industry is doing all these LeetCode style interviews. There are definitely companies out there that are doing things differently and I applaud them for doing that. And I think as awful as it was to have the pandemic shut everything down to early 2020, where no hiring happened, or not a lot of hiring happened over the summer, it did give a lot of companies pause and go, “Well, hey, since we're not hiring, since we got nobody in the backlog, let's examine this whole interview process and let's see if this is really what we want as a company.” And some companies did. They took the time, they took several months and they were like, “You know what, let's burn this whole thing down and start over” as far as their interview process goes. Some of them completely reinvented what their interview process was and turned it into a really great process for candidates to go through. So even if they don't get the job, they still walk away going, “Wow, that was neat.” I think if enough of us start doing that to where candidates then can say, “You know what, I would really prefer not to go through five, or six rounds of interviews” because that's tiring and knowing that what you're kind of what you're in for, with all the LeetCode problems and panel after panel after panel. Like, nobody wants to sit through that. I think if enough candidates stand up for themselves and say, “You know what, I'm looking for a company that has an easier process. So I'm not even going to bother applying.” I think there are enough companies out there that are desperately trying to hire that if they start getting the feedback of like you know what, people don't want to interview with us because our process is lousy. They're going to change the process, but it's going to take time. Unfortunately, it's going to drag out because companies can be stubborn and candidates are also going to be stubborn and it's not going to change quickly. But I think as companies take the step to change their process and enough candidates also step up to say, “Nah, you know what, I was going to apply there,” or “Maybe I got through the first couple of rounds, but you're telling me there's like three more rounds to go through? Nah, I'm not going to bother.” Companies are now starting to see candidates ghost them and walk away from the interview process because they just don't want to be bothered. I think that's a good signal for a company to take a step back and go, “Okay, we need to change our process to make it better so the people do want to apply and enjoy that interview process as they come through.” But it's going to take a while to get there. ARTY: Makes me think about we were talking early on about open source and the power of open source. I wonder with this particular challenge, if you set up a open source hiring manifesto, perhaps of we're going to collaborate on figuring out how to make hiring better. Well, what does that mean? What is it we're aiming for? We took some time to actually clarify these are the things we ought to be aiming for with our hiring process and those are hard problems to figure out. How do we create this alignment between what it is we need to be able to do to be successful day-to-day versus what it is we're selecting for with our interview process? Those things are totally out of whack. I think we're at a point, at least in our industry, where it's generally accepted that how we do interviewing and hiring in these broken things—I think it's generally accepted that it's broken—so that perhaps it's actually a good opportunity right now to start an initiative like that, where we can start collaborating and putting our knowledge together on how we ought to go about doing things better. Even just by starting something, building a community around it, getting some companies together that are working on trying to improve their own hiring processes and learning together and willing to share their knowledge about things that are working better, such that everybody in the industry ultimately benefits from us getting better at these kinds of things. As you said, being able to have an interview process that even if you don't get the job, it's not a miserable experience for everyone involved. [chuckles] Like there's no reason for that. IAN: Yeah. MANDY: That's how we – I mean, what you just explained, Arty isn't that how we got code of conducts? Everybody's sitting down and being like, “Okay, this is broken. Conferences are broken. What are we going to all do together?” So now why don't we just do the same thing? I really like that idea of starting an open source initiative on interviewing. Like have these big FAANG companies be like, “I had a really great interview with such and such company.” Well, then it all spirals from there. I think that's super, super exciting. ARTY: Yeah. And what is it that made this experience great? You could just have people analyze their interview experiences that they did have, describe well, what are the things that made this great, that made this work and likewise, you could collect anti-patterns. Some of the things that you talked about of like, are we interviewing for geolocation skills when that actually has absolutely nothing to do with our business? We could collect these things as these funky anti-patterns of things so that people could recognize those things easier in there because it's always hard to see yourself. It's hard to see yourself swinging. IAN: An interesting idea along those lines is what if companies said like, “Hey, we want the community to help us fix our interview process. This is who we are, this is what our business does. What kinds of questions do you think we should be asking?” And I think that the community would definitely rally behind that and go, “Oh, well, you're an e-commerce platform so you should be asking people about shopping cart implementations and data security around credit cards and have the interview process be about what the company actually does.” I think that that would be an interesting thing to ask the community like, “What do you think we should be asking in these interviews?” Not that you're going to turn around and go, “Okay, that's exactly what we're going to do,” but I think it'll give a lot of companies ideas on yeah, okay, maybe we could do a take-home assignment where you build a little shopping cart and you submit that to us. We'll evaluate how you did, or what you changed, or we're going to give you some code to start with and we're going to ask you to fix a bug in it, or something like, I think that there's a bigger movement now, especially here in Canada, in the US of doing take-home assignments. But I think at the same time, there are pros and cons of doing take-home assignments versus the on-site technical challenges. But what if we gave the candidate a choice as part of that interview process, too and say, “Hey, cool. We want to interview you. Let's get through the phone screen and now that you've done the phone screen, we want to give you the option of, do you want to do a small take-home assignment and then do a couple of on-site technical challenges? Do you want to do a larger take-home and maybe fewer on-site technical challenges?” I think there's always going to be some level of “Okay, we need to see you code in front of us to really make sure that you're the one that wrote that code.” I got burned on that back in 2012 where I thought somebody wrote some code and they didn't. They had a friend write it as their take-home assignment and so, I brought them in for the interview and I'm like, “Cool, I want you to fix this bug,” and they had no idea what to do. They hadn't even looked at the code that their friend wrote for them it's like, why would you do that? So I think that there's always going to be some amount of risk and trust that needs to take place between the candidates and the companies. But then on the flip side of that, if it doesn't work out, I really wish companies would be better about giving feedback to people instead of just ghosting them, or like, “Oh, you didn't and pass that round. So we're just not even going to call you back and tell you no. We're just not ever just going to call.” The whole ghosting thing is, by far, the number one complaint in the tech industry right now is like, “I applied and I didn't even get a thanks for your resume. I got nothing,” or maybe you get some automated reply going, “We'll keep you in mind if you're a match for something.” But again, those apple looking at tracking systems are biased because the developers building them and the people reading the resumes are going to have their own inherent bias in the search terms and the things that they're looking for and so on. So there's bias all over the place that's going to be really hard to get rid of. But I think if companies were to take a first step and say like, “Okay, we're going to talk to the community about what they would like to see the interview process be,” and start having more of those conversations. And then I think as we see companies step up and make those changes, those are going to be the kinds of companies where people are going to rally behind them and go, “I really want to work there because that interview process is pretty cool.” And that means the company is – well, it doesn't guarantee the company's going to be cool, but it shows that they care about the people that are going to work there. If people know that the company is going to care about you as an employee, you're far more likely to want to work there. You're far more likely to be loyal and stay there for a long term as opposed to like oh, I just need to collect a paycheck for a year to get a little bit of experience and then job hop and go get a better title, better pay. So I think it can come down to company loyalty and stuff, too. MANDY: Yeah. Word of mouth travels fast in this industry. IAN: Absolutely. MANDY: And to bring up the code of conduct thing and now people are saying, “If straight up this conference doesn't have a code of conduct, I'm not going.” IAN: Yeah. I agree. It'll be interesting to see how something like this tech interview overhaul open source idea could pick up momentum and what kinds of companies would get behind it and go, “Hey, we think our interview process is pretty good already, but we're still going to be a part of this and watch other companies step up to.” When I talked earlier about that ripple effect where Google, for example, stopped asking how many golf balls fit in a school bus kind of thing and everyone else is like, “Yeah, those questions are dumb.” We actually saw this summer, Facebook and Amazon publicly say, “We're no longer going to ask dynamic programming problems in our interviews.” It's going to be interesting to see how long that takes to ripple out into the industry and go, “Yeah, we're not going to ask DP problems either,” because again, people want to be those big companies. They want to be billion- and trillion-dollar companies, too and so, they think they have to do everything the same way and that's not always the case. But there's also something broken in the system, too with hiring. It's not just the interview process itself, but it's also just the lack of training. I've been guilty of this myself, where I've got an interview with somebody and I've got back-to-back meetings. So I just pull someone on my team and be like, “Hey, Arty, can you come interview this person?” And you're like, “I've never interviewed before. I guess, I'll go to LeetCode and find a problem to give them.” You're walking in there just as nervous as the candidate is and you're just throwing some technical challenge at them, or you're giving them the technical challenge that you've done most recently, because you know the answer to it and you're like, “Okay, well, I guess they did all right on it. They passed,” or “I think they didn't do well.” But then companies aren't giving that feedback to people either. There's this thinking in the industry of oh, if we give them feedback, they're going to sue us and they're going to say it's discriminatory and they're going to sue us. Aline Lerner from interviewing.io did some research with her team and literally nobody in recent memory has been sued for giving feedback to candidates. If anything, I think that it would build trust between companies and the candidates to say, “Hey, this is what you did. Well, this is what we thought you did okay on. We weren't happy with the performance of the code that you wrote so we're not moving forward,” and now you know exactly what to go improve. I was talking to somebody who was interviewing at Amazon lately and they said, “Yeah, the recruiter at Amazon said that I would go through all these steps,” and they had like five, or six interviews, or something to go through. And they're like, “Yeah, and they told me at the end of it, we're not going to give you any feedback, but we will give you a yes, or no.” It's like so if I get a no, I don't even find out what I didn't do well. I don't know anything about how to improve to want to go apply there in the future. You're just going to tell me no and not tell me why? Why would I want to reapply there in the future if you're not going to tell me how I'm going to get better? I'm just going to do the same thing again and again. I'm going to be that little toy that just bangs into the wall and doesn't learn to steer away from the wall and go in a different direction. If you're not going to give me any feedback, I'm just going to keep banging my head against this wall of trying to apply for a job and you're not telling me why I'm not getting it. It's not helpful to the candidate and that's not helpful to the industry either. It starts affecting mental health and it starts affecting other things and I think it erodes a lot of trust between companies and candidates as well. ARTY: Yeah. The experience of just going through trying to get a job and going through the rejection, it's an emotional experience, an emotionally challenging experience. Of all things that affect our feels a lot, it's like that feeling of social rejection. So being able to have just healthier relationships and figuring out how to see another person as a human, help figure out how you can help guide and support them continuing on their journey so that the experience of the interview doesn't hurt so much even when the relationship doesn't work out, if we could get better at those kinds of things. There's all these things that if we got better at, it would help everybody. IAN: I agree. ARTY: And I think that's why a open source initiative kind of thing maybe make sense because this is one of those areas that if we got better at this as an industry, it would help everybody. It's worth putting time in to learn and figure out how we can do better and if we all get better at it and stuff, there's just so many benefits and stuff from getting better at doing this. Another thing I was thinking about. You were mentioning the language thing of how easy it is to map skills that we learned from one language over to another language, such that even if you don't know the language that they're coding in at a particular job, you should apply anyway. [chuckles] I wonder if we had some data around how long it takes somebody to ramp up on a new language when they already know similar-ish languages. If we had data points on those sort of things that we're like, “Okay, well, how long did it actually take you?” Because of the absence of that information, people just assume well, the only way we can move forward is if we have the unicorn skills. Maybe if it became common knowledge, that it really only takes say, a couple months to become relatively proficient so that you can be productive on the team in another language that you've never worked in before. Maybe if that was a common knowledge thing, that people wouldn't worry about it so much, that you wouldn't see these unicorn recruiting efforts and stuff. People would be more inclined to look for more multipurpose general software engineering kinds of skills that map to whatever language that you're are doing. That people will feel more comfortable applying to jobs and going, “Oh, cool. I get the opportunity to learn a new language! So I know that I may be struggling a bit for a couple months with this, but I know I'll get it and then I can feel confident knowing that it's okay to learn my way through those things.” I feel if maybe we just started collecting some data points around ramp up time on those kind of things, put a database together to collect people's experiences around certain kind of things, that maybe those kinds of things would help everyone to just make better decisions that weren't so goofy and out of alignment with reality. IAN: Yeah, and there are lots of cheat sheets out there like, I'm trying to remember the name of it. I used to have it bookmarked. But you could literally pull up two programming languages side by side in the same browser window and see oh, if this is how you do it in JavaScript, this is how you do it on Python, or if this is how you write this code in C++, here's how you do it in Java. It gives you a one-to-one correlation for dozens, or hundreds of different kinds of blocks of code. That's really all you need to get started and like you said, it will take time to come proficient to where you don't have to have that thing up on your screen all the time. But at the same time, I think the company could invest and say, “You know what, take a week and just pour everything you've got into learning C Sharp because that's the skill we want you to have for this job.” It's like, okay, if you are telling me you trust me and you're making me the job offer and you're going to pay me this salary and I get to work in tech, but I don't happen to have that skill, but you're willing to me in that skill, why would I not take that job? You're going to help me learn and grow. You're offering me that job with a salary. Those are all great signals to send. Again, I think that a lot of companies are missing out and they're like, “No, we're not going to hire that person. We're just going to hold out until we find the next person that's a little bit better.” I think that that's where some things really drop off in the process, for sure is companies hold out too long and next thing they know, months have gone by and they've wasted tons of money when they could have just hired somebody a long time ago and just trained them. I think the idea of an open source collective on something like this is pretty interesting. At the same time, it would be a little subjective on “how quickly could someone ramp up on a, or onboard on a particular technology.” Because everybody has different learning styles and unless you're finding somebody to curate – like if you're a Ruby programmer and you're trying to learn Python, this is the de facto resource that you need to look at. I think it could be a little bit subjective, but I think that there's still some opportunity there to get community input on what should the interview process be? How long should it really be? How many rounds of interviews should there be from, both the candidates experience as well as the company experience and say, as a business, this is why we have you doing these kinds of things. That's really what I've been to teach as part of the Tech Interview Guide and the daily email series is from my perspective in the business, this is why. This is why I have you do a certain number of rounds, or this is why I give you this kind of technical challenge, or this is why I'm asking you this kind of question. Because I'm trying to find these signals about you that tell me that you're someone that I can trust to bring on my team. It's a tough system when not many people are willing to talk about it because I think a lot of people are worried that others are going to try to game the system and go, “Oh, well, now that I know everything about your interview process, I know how to cheat my way through it and now you're going to give me that job and I really don't know what I'm doing.” But I think that at the same time, companies can also have the higher, slow fire, fast mentality of like, “All right, you're not cutting it.” Like you're out right away and just rehire for that position. Again, if you're willing to trust and willing to extend that offer to begin with. If it doesn't work out, it doesn't work out. It's a business decision; it's not a personal thing. But it's still devastating to the person when they don't get the job, or if they get fired right away because they're not pulling their weight, but if they're cheating their way through it, then they get what they deserve to. MANDY: Awesome. Well, I think that's a great place to put a pin in this discussion. It is definitely not a great place to end it. I think we should head over to our reflection segment. For me, there were so many things I wrote down. I loved that you said that people's tech journey is like a choose your own adventure. You can learn one thing and then find yourself over here and then the next thing you know, you find yourself over here. But you've picked up all these skills along the way and that's the most important thing is that as you go along this journey, you keep acquiring these skills that ultimately will make you the best programmer that you can be. Also, I really like that you also said something about it being a lifelong learning. Tech is lifelong learning and not just the technical skills. It's the people skills. It's the behavioral skills. Those are the important skills. Those skills are what ultimately it comes down to being in this industry is, do you have the desire to learn? Do you have the desire to grow? I think that should be one of the most important things that companies are aware of when they are talking to candidates that it's not about can this person do a Fibonacci sequence. It's can they learn, are they a capable person? Are they going to show up? Are they going to be a good person to have in the office? Are they going to be a light? Are they going to be supportive? Are they going to be caring? That's the ultimate. That right there for me is the ultimate and thank you for all that insight. ARTY: Well, I really, really loved your story, Ian at the very beginning of just curiosity and how you started your journey, getting into programming and then ended up finding ways to give back and getting really excited about seeing people's light bulbs go off and how much joy you got from those experiences, connecting with another individual and making that happen. I know we've gotten on this long tangent of pretty abstract, big topics of just like, here's the brokenness in the industry and what are some strategies that we can solve these large-scale problems. But I think you said some really important things back of just the importance of these one-on-one connections and the real change happens in the context of a relationship. Although, we're thinking about these big things. To actually make those changes, to actually make that difference, it happens in our local context. It happens in our companies. It happens with the people that we interact with on a one-on-one basis and have a genuine relationship with. If we want to create change, it happens with those little ripples. It happens with affecting that one relationship and that person going and having their own ripple effects. We all have the power to influence these things through the relationships with the individuals around us. IAN: I think my big takeaway here is we have been chatting for an hour and just how easy it is to have conversation about hey, what if we did this? How quickly it can just turn into hey, as a community, what if? And just the willingness of people being in the community, wanting to make the community better,

Tech Unlocked
EP 48 | How to get unstuck and make successful career transitions with Linda Vivah

Tech Unlocked

Play Episode Listen Later Nov 23, 2021 55:53


Do you currently feel stuck in your career? Do you want to make a career transition but don't know how to start? This is the perfect episode for you! Today on the show, Grace chats with Linda Vivah a Software Engineer, an AWS Community Builder, a mom of 2, a part-time wedding singer &  founder of Coding Crystals about how to get unstuck in your career and develop the mindset needed to make successful career transitions.    Linda Vivah is a Software Engineer at a major media organization in NYC, an AWS Community Builder, a mom of 2, a part-time wedding singer & the founder of a shop called Coding Crystals: a jewelry & accessories company taking inspiration from STEM. She creates content around tech including coding, cloud computing, career tips with a sprinkle of lifestyle. Linda had an untraditional journey into tech and broke into tech post-college via self-studying and attending a coding bootcamp. She currently works as an SRE (Site Reliability Engineer). She was previously working as a Web Application Developer (mainly JavaScript) for 5 years and transitioned from Web Development to an SRE role last year to be more hands-on in the cloud computing space.  Key takeaways: How to shift your mindset when you feel stuck in your career Practical tips for getting unstuck in your career How to learn a new skill while balancing your day job Why most people in tech experience imposter syndrome  The truth about coding bootcamps Top 3 things you should look for in your first tech job Resources: AWS Certified Cloud Practitioner (CLF-C01) The Cloud Resume Challenge AWS Certified Solutions Architect – Associate Flatiron Bootcamp Follow Tech Unlocked for career tips: Website Substack Twitter Instagram   Connect with Grace: Instagram Twitter LinkedIn   Connect with Linda: Instagram TikTok YouTube Twitter Medium Coding Crystals Shop   Enjoyed listening to this episode? Please leave a review on iTunes and Spotify. Questions about sponsorship? Email us techunlockedpod@gmail.com    

The CyberWire
Using bidirectionality override characters to obscure code. [Research Saturday]

The CyberWire

Play Episode Listen Later Nov 20, 2021 26:25


Guests Nicholas Boucher and Ross Anderson from the University of Cambridge join Dave Bittner to discuss their research, "Trojan Source: Invisible Vulnerabilities." The researchers present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards such as Unicode to produce source code whose tokens are logically encoded in a different order from the one in which they are displayed, leading to vulnerabilities that cannot be perceived directly by human code reviewers. ‘Trojan Source' attacks, as they call them, pose an immediate threat both to first-party software and of supply-chain compromise across the industry. They present working examples of Trojan-Source attacks in C, C++, C#, JavaScript, Java, Rust, Go, and Python. They propose definitive compiler-level defenses, and describe other mitigating controls that can be deployed in editors, repositories, and build pipelines while compilers are upgraded to block this attack. The project website and research can be found here: Trojan Source: Invisible Source Code Vulnerabilities project website Trojan Source: Invisible Vulnerabilities research paper

Research Saturday
Using bidirectionality override characters to obscure code.

Research Saturday

Play Episode Listen Later Nov 20, 2021 26:25


Guests Nicholas Boucher and Ross Anderson from the University of Cambridge join Dave Bittner to discuss their research, "Trojan Source: Invisible Vulnerabilities." The researchers present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards such as Unicode to produce source code whose tokens are logically encoded in a different order from the one in which they are displayed, leading to vulnerabilities that cannot be perceived directly by human code reviewers. ‘Trojan Source' attacks, as they call them, pose an immediate threat both to first-party software and of supply-chain compromise across the industry. They present working examples of Trojan-Source attacks in C, C++, C#, JavaScript, Java, Rust, Go, and Python. They propose definitive compiler-level defenses, and describe other mitigating controls that can be deployed in editors, repositories, and build pipelines while compilers are upgraded to block this attack. The project website and research can be found here: Trojan Source: Invisible Source Code Vulnerabilities project website Trojan Source: Invisible Vulnerabilities research paper

React Native Radio
RNR 218 - Performance Enhancing Drugs for your React Native app with Mark Rickert Part 2

React Native Radio

Play Episode Listen Later Nov 19, 2021 41:26


In the second of this two-part series, Mark Rickert joins the podcast to talk about performance-tuning your React Native apps. This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.Helpful Links:useMemo & useCallbackUse React Memo WiselyDon't overuse React useCallbackrequestAnimationFrameRedux Performance tipsInteractionManagerTurboModules and FabricReact State MuseumConnect With Us!React Native Radio: @ReactNativeRdioJamon - @jamonholmgrenJon Major - @jonmajorcMark -  @markrickertMazen - @mazenchami

Changelog Master Feed
Sophie is the bomb diggity (JS Party #202)

Changelog Master Feed

Play Episode Listen Later Nov 19, 2021 67:17


This week we are joined by Sophie Alpert, Head of Engineering at Humu, and former lead of the React Core team, to discuss her experience on being a very early adopter, contributor, and eventually maintainer of React. In her 4+ years on the Core team, she went from supporting a new niche OSS UI library to supporting a project used by millions of developers around the world. Join us to hear about this epic journey, as well as Sophie's thought's on some common critiques and misconceptions of React.

Syntax - Tasty Web Development Treats
Potluck — Copilot × Glasses × Databases × Dealing with Stress × Employment vs Self-Employment × Auth in GraphQL × Headless CMS × More!

Syntax - Tasty Web Development Treats

Play Episode Listen Later Nov 17, 2021 57:44


It's another Potluck! In this episode, Scott and Wes answer your questions about GitHub Copilot, glasses, databases, dealing with stress, self-employment vs employment, design, CORS, and much more! Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” section. Show Notes 03:12 - Ders: Has GitHub Copilot become part of your daily workflow, or have you turned it off? 05:50 - Gaston Gmzi: Hey guys you rock!!! I'd like to know if you use eyeglasses and if you have any preference regarding models, design and features like blue-light blocking and anti-reflection. Also, where do you buy them? Do you go to a store to try them out, or do you buy them online? And if ordering online, which specifications do you use besides the doctor's prescription? If you guys have any sick picks about eyeglasses it would be great to hear it too. Thanks for the show and have a great week!!! 11:04 - Hi, I would like to know how the two of you deal with stress? I am a freelancer and sometimes clients can get the worst in me. When they do, I usually take a long walk and listen to a podcast, but I don't always have the time for that. I can actually go into my commit history and show which one was under stress. I think a lot of developers especially freelancers could benefit from that. Thanks. 16:47 - Mike Varela: Question for you guys about dynamic database fields and API requests. How do you let the user store dynamic metadata? Thanks. Love the show, avid listener. 21:04 - Valentine Michael Smith: Can you touch on the use of the word “grok” in the dev world? I know a lot of people who have no idea what this word means. I just happened to have tried to read Stranger in a Strange Land, the novel the word originated from, a few years ago or else I wouldn't have ever heard it before starting dev work. Have either of you read the book? Anyways, why do devs say this? 24:50 - Steve Lewis: If you guys were not self-employed, would you prefer to work for a big company (like FAANG) or go to a smaller agency or startup, etc.? 27:08 - So Many Localhost Errors: This may be a softball, but how do you set up your logging (Sentry and/or LogRocket) so your dev environment isn't firing all the time? I can't seem to find a way to do this well (and it's probably because I'm trying to learn as I go). 31:03 - Josh J from Jersey: Hey guys, loving the podcast, I've been listening for about a month but bingeing through your episodes during my mind-numbing warehouse job, helps me keep my mind on JavaScript and what I have managed to learn in my spare time. I was wondering, when you're sitting down to a new project, how do you design the website? Does it just slowly develop as you code or have you sat down and drawn out what you want it to look like ahead of time? I have heard talk of a remarkable pad. I've seen ads for this on Instagram and YouTube but always assumed it was a very gimmicky thing. Is this a good investment? Also wondering how you both met? Have you worked on any projects together outside of courses and Syntax? Keep the content coming! 38:14 - Andras: Hi Wes and Scott. You have talked a lot on the show about headless CMS's like Sanity, Prismic or even WordPress being used as a headless CMS. I am curious what the setup in a real world project is like. How would you host the CMS? And what will the admin surface look like? Will the button styles, background color etc. be different than the actual website that the end user sees? Is that a problem for the admin users? Does the admin user see all the menu for creating new content types or adding new features? Or do they only see the input fields of all the contents that can be added to a specific page? Thank you! 42:14 - Dave: Hey guys, love the podcast! I understand that CORS prevention is in place in the browser to help improve security/prevent malicious requests across domains, but I don't understand why you can get around this by performing the request server side, for example via cURL? If I were a malicious actor, surely I could just send my cross domain request through a proxy to avoid the CORS issue? I'm sure I'm missing something obvious here, can I please get your thoughts on this? 44:48 - Lemon: How do you implement authentication with GraphQL? Especially in Fastify, I know Scott recently moved over from Meteor to Fastify, so I too was checking Fastify but couldn't find a satisfying auth solution that fits well with GraphQL. 48:08 - Zack Vogel: I love when you play games on the podcast. I'm a high school technology teacher and I play a game with my students called the 5 Second Rule. It's based on a board game, but I have changed the topics to technology-themed questions. The game works like this. One person reads a topic “Name Three VS Code Extensions” and the other person has five seconds to respond with three correct answers. I think this could be a fun game to play on the podcast. Links http://www.seeeyewear.com/ https://www.warbyparker.com/ https://www.costco.com/ MariaDB dynamic columns https://en.wikipedia.org/wiki/Grok https://twitter.com/argyleink https://remarkable.com/ https://figma.com/ https://graphql.org/ https://www.meteor.com/ https://www.fastify.io/ https://docs.google.com/presentation/d/1oRqz1rSUXiLc5pJF2cMygNrodcRrRU77x0KdWGV67Iw/edit?usp=sharing ××× SIIIIICK ××× PIIIICKS ××× Scott: myQ Chamberlain Smart Garage Control Wes: ATOTO Head Unit Shameless Plugs Scott: Level Up Tutorials Pro - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code ‘Syntax' for $10 off! Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Growth Mindset Podcast
191: Elizebeth Tweedale, CEO CypherCoders: How Learning to Code is the Answer to Everything, Mindsets in Business and Learning, Is it Better to Have Cofounders or be a Solo Founder, Raising Money as a Female Founder.

Growth Mindset Podcast

Play Episode Listen Later Nov 16, 2021 49:20


Elizabeth is the CEO and Founder of Cypher Coders, the UK's leading coding school for children, as well as a highly experienced AI creator, author and entrepreneur. Her mission is to empower children to move freely and confidently through the changing world around us, fluent in the universal language of code in order to become future-ready. CONNECT WITH ELIZABETH Cypher Coders (www.cyphercoders.com) LinkedIn (https://www.linkedin.com/in/elizabethtweedale) Instagram (https://www.instagram.com/nottinghillmummy) Twitter (https://twitter.com/nottinghillmmmy) ABOUT THE HOST My name is Sam Harris. I am a British entrepreneur, investor and explorer. From hitchhiking across Kazakstan to programming AI doctors I am always pushing myself in the spirit of curiosity and Growth. My background is in Biology and Psychology with a passion for improving the world and human behaviour. I have built and sold companies from an early age and love coming up with unique ways to make life more enjoyable and meaningful. Connect with Sam: Instagram (https://www.instagram.com/samjamharris/) Twitter (https://twitter.com/samjamharris) LinkedIn (https://www.linkedin.com/in/sharris48/) Wiser than Yesterday (https://www.wiserpod.com) ReasonFM (https://reason.fm/podcast/growth-mindset-podcast) Sam's blog - SamWebsterHarris.com (https://samwebsterharris.com/) Support the Show - Patreon (https://www.patreon.com/growthmindset) Subscribe! If you enjoyed the podcast please subscribe and rate it. And of course, share with your friends! Special Guest: Elizabeth Tweedale.

Enjoy the Vue
Episode 81: Advanced CSS 101 with Josh Comeau

Enjoy the Vue

Play Episode Listen Later Nov 15, 2021 72:12


The focus of today's show is the divisive topic of CSS. There are many different opinions on the strengths, weaknesses, and value of CSS, and to explore this in some detail, we are lucky enough to have Josh Comeau join us on our extended panel! One of the strongest messages that comes through from our discussion is the amount of time and effort that CSS requires you to invest, to reap its benefits. And while not every developer will agree to this exchange, it is hard to argue that certain parts of CSS can make this a worthwhile endeavor. We talk about the ever-increasing complexity of CSS and how this has occurred over time as the language has been added to. We also get into our favorite parts and features, looking at variables, current color, and a whole lot more. So, to hear it all from our team and our great guest, Josh Comeau, be sure to listen in with us today, on Enjoy the Vue! Key Points From This Episode: Opening remarks about CSS and thoughts on overcoming its challenges. How continually adding to the CSS language has increased its complexity over time.  Weighing the best and worst additions to CSS: exciting features and things that have not worked so well.  The original intentions for CSS and its place among other tools for web development.  The difficulties with improving your CSS skills and the issue of the lack of error messages.  Favorite CSS properties: current color, variables, tricks, and more!  The infinite possibilities of tooltips. Tackling the issues of absolute positioning through spending time with them.  Comparing the different web browsers and the most frustrating bugs. Questions of specificity and the hidden mechanisms around sufficient information.   Top recommendations for getting better at CSS and Josh's helpful course!  The availability of great tools and finding the ones that work for you.   This week's pics: the new MacBook Pro, Remarkable Tablet, Sweet Home, and more! Tweetables: “I started trying to really understand CSS. I really, really enjoy the language now. It's become probably my favorite part of doing web development.” — @JoshWComeau (https://twitter.com/JoshWComeau) [0:05:55] “I do think that right now is an incredibly exciting time to be a CSS person because so many amazing things are right on the horizon." — @JoshWComeau (https://twitter.com/JoshWComeau) [0:11:30] “That's what leads to that feeling that CSS is unpredictable and inconsistent. It's not. It's just that if you only have one of the puzzle pieces, of course, it's not going to seem consistent.” — @JoshWComeau (https://twitter.com/JoshWComeau) [0:40:29] Links Mentioned in Today's Episode: Table Caption (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/caption) Rachel Andrew (https://rachelandrew.co.uk) Firefox Developer Tools (https://developer.mozilla.org/en-US/docs/Tools) Improve SMIL "Parsing timing specifiers" instructions #722 (https://github.com/w3c/svgwg/issues/722), Oscar Spencer (W3) CSS SpeciFISHity (https://specifishity.com), Estelle Weyl Stacking Contexts (https://www.joshwcomeau.com/css/stacking-contexts), Josh Comeau CSS Stacking Context inspector (https://chrome.google.com/webstore/detail/css-stacking-context-insp/apjeljpachdcjkgnamgppgfkmddadcki), Andrea Dragotta (Chrome Extension) Debug your website in 3D (https://youtu.be/BZAH8ZXhHZA), Edge Dev Team Learn CSS (https://web.dev/learn/css), Google Glamorous (https://kentcdodds.com/blog/introducing-glamorous), Kent C. Dodds G733 Lightspeed Wireless RGB Gaming Headset (https://www.logitechg.com/en-us/products/gaming-audio/g733-rgb-wireless-headset.981-000942.html), Logitech Astrolokeys (https://astrolokeys.com), Amy Wibowo and Cassidy Williams 3.5mm EarPods (https://www.apple.com/shop/product/MNHF2AM/A/earpods-with-35-mm-headphone-plug), Apple Twitter: joshwcomeau (http://twitter.com/joshwcomeau) Blog: joshwcomeau.com (http://joshwcomeau.com) The Long Way to a Small, Angry Planet (https://bookshop.org/books/the-long-way-to-a-small-angry-planet/9780062444134), Becky Chambers Champion Sports Lacrosse Balls (https://www.amazon.com/dp/B000KA4OE8) Golden Girls Quotes API (https://github.com/ashleemboyer/the-golden-girls-quotes-api)  ReMarkable Tablet (https://remarkable.com/) CSS for JavaScript Developers (https://courses.joshwcomeau.com/css-for-js), Josh Comeau Comic Parchment (https://laughingsquid.com/comic-papyrus), Ben Harman Buy font (https://crmrkt.com/yoMDE6) (referral link) Play It as It Lays (https://bookshop.org/books/play-it-as-it-lays/9780374529949), Joan Didion Sweet Home (https://www.netflix.com/watch/81061734), Netflix Special Guests: Jenell Pizarro and Josh Comeau.

No Plans to Merge
Home Automation

No Plans to Merge

Play Episode Listen Later Nov 12, 2021 79:21


Changelog Master Feed
The inside story on React's all new docs (JS Party #201)

Changelog Master Feed

Play Episode Listen Later Nov 12, 2021 74:09


Rachel Nabors –beloved educator, animator, & documentation engineer at Meta– joins Amal and Amelia for a first look at the brand new React docs! This massive overhaul to the React website (which supports 2 million+ developers around the world) was no easy feat! We dive into all the behind the scenes coordination, as well of the goals, wins, and intended outcomes of this new way of approaching educational content and API reference material for open source projects.

Svelte Radio
Rich Harris is now working full-time on Svelte

Svelte Radio

Play Episode Listen Later Nov 12, 2021 69:16


We sit down with Rich Harris to talk about his new job, leaving The New York Times and what the future of Svelte looks like. Enjoy!Description Remembering some New York Times stories The Follower Factory The Surveillance Economy  Corona Tracker Olympics Graphics Joining Vercel to work full time on Svelte Svelte Summit  Watch Parties New York Mainz, Germany Music by Fractal (He also made the intro to Svelte Radio

Black Hills Information Security
Talkin' About Infosec News – 11/12/2021

Black Hills Information Security

Play Episode Listen Later Nov 12, 2021 43:19


ORIGINALLY AIRED ON November 08, 2021 Articles discussed in this episode: 00:00 – PreShow Banter™ — God's Waiting Room 03:08 – BHIS – Talkin' Bout [infosec] News 2021-11-08 04:50 – Story # 1: JavaScript in Excel – https://techcrunch.com/2021/11/02/microsoft-brings-javascript-to-excel/ 09:12 – Story # 2: Bots That Steal 2FA Codes – https://www.vice.com/en/article/y3vz5k/booming-underground-market-bots-2fa-otp-paypal-amazon-bank-apple-venmo 13:00 – Story # 3: […] The post Talkin' About Infosec News – 11/12/2021 appeared first on Black Hills Information Security.

PodRocket - A web development podcast from LogRocket
Vanilla JavaScript with Chris Ferdinandi

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Nov 12, 2021 48:21


We talk to Chris Ferdinandi about vanilla JavaScript, the modern web, newsletters, and more. Links https://gomakethings.com/podrocket http://vanilla-js.com https://preactjs.com https://alpinejs.dev https://www.npmjs.com/package/petite-vue https://css-tricks.com/radeventlistener-a-tale-of-client-side-framework-performance https://svelte.dev https://kit.svelte.dev https://astro.build https://twitter.com/jlengstorf/status/1442707241627385860 https://moderncss.dev https://smolcss.dev Contact us https://podrocket.logrocket.com/contact-us @PodRocketpod (https://twitter.com/PodRocketpod) What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Chris Ferdinandi.

Cyber Humanity
47: Drone Strikes and Cyber Heists

Cyber Humanity

Play Episode Listen Later Nov 12, 2021 43:50


NPM packages are getting hacked – so naturally we get Kev on the case to explain the whole thing. If you didn't know, NPM is the official package manager for Node libraries, a JavaScript language. We've seen a big uptake in recent weeks, and some of those NPM packages have been compromised by hackers. They're clearly targeting developers – and with a collective 28 million downloads every week, this is pretty big, wide-spread stuff. Next up, the raft of ransomware stories from this week: from the UK's Labour Party to a…“cyber heist”?  We've also noticed a bit of a theme emerging with an increase in government and law enforcement involvement in disrupting ransomware and other cyber criminal enterprises. BlackMatter is our example here.  *** https://www.dailymail.co.uk/news/article-10148265/Massive-cyber-heist-rocks-high-society-jeweller-Graff.html https://www.bleepingcomputer.com/news/security/blackmatter-ransomware-claims-to-be-shutting-down-due-to-police-pressure/ https://thehackernews.com/2021/10/popular-npm-package-hijacked-to-publish.html

Cloud Accounting Podcast
Intuit Kills QuickBooks Desktop

Cloud Accounting Podcast

Play Episode Listen Later Nov 12, 2021 68:23


SponsorsPractice Ignition: https://cloudaccountingpodcast.promo/piCenterCard:  https://cloudaccountingpodcast.promo/centerClient Hub: https://cloudaccountingpodcast.promo/clienthubNeed CPE? Subscribe to the Earmark Accounting Podcast: https://podcast.earmarkcpe.comGet CPE for listening to podcasts with Earmark CPE: https://earmarkcpeShow NotesComing soon! Get in TouchThanks for listening and for the great reviews! We appreciate you! Follow and tweet @BlakeTOliver and @DavidLeary. Find us on Facebook and, if you like what you hear, please do us a favor and write a review on iTunes, or Podchaser. Interested in sponsoring the Cloud Accounting Podcast? For details, read the prospectus, and NOW, you can see our smiling faces on Instagram! You can now call us and leave a voicemail, maybe we'll play it on the show. DIAL (202) 695-1040Need Accounting Conference Info? Check out our new website - accountingconferences.comLimited edition shirts, stickers, and other necessitiesTeePublic Store: http://cloudacctpod.link/merchSubscribe Apple Podcasts: http://cloudacctpod.link/ApplePodcasts Podchaser: http://cloudacctpod.link/podchaser Spotify: http://cloudacctpod.link/Spotify Google Play: http://cloudacctpod.link/GooglePlay Stitcher: http://cloudacctpod.link/Stitcher Overcast: http://cloudacctpod.link/Overcast ClassifiedsFuture Firm: https://futurefirmaccelerate.com/Accounting Podcast Network: https://accountingpodcastnetwork.com/Go here to create your classified ad: https://cloudacctpod.link/RunClassifiedAd  Want to get the word out about your newsletter, webinar, party, Facebook group, podcast, e-book, job posting, or that fancy Excel macro you just created? Why not let the listeners of The Cloud Accounting Podcast know by running a classified ad? Hit the show notes for the link to get more info.Full Transcript Available Upon Request - info@cloudaccountingpodcast.com

HTML All The Things - Web Development, Web Design, Small Business
The Front-End Developer Roadmap (Revisited)

HTML All The Things - Web Development, Web Design, Small Business

Play Episode Listen Later Nov 10, 2021 81:03


In this episode Matt and Mike discuss front-end development, covering a roadmap of skills that can be used as a sort of guide through the many front-end technologies. The duo go over a list of topics that you can use to learn front-end development starting at vanilla HTML + CSS, and working into more complex topics like frameworks, JavaScript, some backend tech, and much more.   You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub

The ReadME Podcast
Giving 110% in the right place at the right time

The ReadME Podcast

Play Episode Listen Later Nov 9, 2021 48:24


Fred Schott's love for programming started early, and he worked hard during his 20s at companies like Box and Google. As his own side projects experienced open source success, Fred took the plunge in 2021 and started Astro, a JavaScript-based static site builder full time. In this conversation, he speaks about his introduction to open source, his path to Astro, and the role luck plays in success. Fred on GitHub: https://github.com/fredkschott Astro on the web: https://astro.build/blog/introducing-astro/ Be sure to check-out The ReadME Project for more episodes, stories and features: https://github.com/readme

Machine Learning – Software Engineering Daily
Learning Tensorflow.js with Gant Laborde

Machine Learning – Software Engineering Daily

Play Episode Listen Later Nov 9, 2021 51:21


Machine learning models must first be trained.  That training results in a model which must be serialized or packaged up in some way as a deployment artifact.  A popular deployment path is using Tensorflow.js to take advantage of the portability of JavaScript, allowing your model to be run on a web server or client. Gant The post Learning Tensorflow.js with Gant Laborde appeared first on Software Engineering Daily.

Software Engineering Daily
Learning Tensorflow.js with Gant Laborde

Software Engineering Daily

Play Episode Listen Later Nov 9, 2021 51:21


Machine learning models must first be trained.  That training results in a model which must be serialized or packaged up in some way as a deployment artifact.  A popular deployment path is using Tensorflow.js to take advantage of the portability of JavaScript, allowing your model to be run on a web server or client. Gant The post Learning Tensorflow.js with Gant Laborde appeared first on Software Engineering Daily.

Paul's Security Weekly TV
Linux Kernel TIPC RCE, NPM Malware, OTP 2FA Bots, & Security Labels - ASW #173

Paul's Security Weekly TV

Play Episode Listen Later Nov 9, 2021 38:44


This week in the AppSec News, Mike and John talk: Excel gains support for JavaScript data types and functions, arbitrary code execution in Linux kernel TIPC, more malware in npm packages, threat models and OTP/2FA bots, NIST Security Labels!   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw173

Paul's Security Weekly
Schools of Magic - ASW #173

Paul's Security Weekly

Play Episode Listen Later Nov 9, 2021 73:58


This week, Mike, John and Dan McKinney from Cloudsmith will be discussing SBOM and what that looks like for your applications. Other topics include: cloud-native tooling for your software supply chain, the history of provenance, GPG Keys & signing commits, package consumption, understanding threat modeling, and knowing the roles and responsibilities when it comes to security of your assets.   In the AppSec News, Mike and John talk: Excel gains support for JavaScript data types and functions, arbitrary code execution in Linux kernel TIPC, more malware in npm packages, threat models and OTP/2FA bots, NIST Security Labels!   Show Notes: https://securityweekly.com/asw173 Visit https://securityweekly.com/cloudsmith to learn more about them!   Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly

The Bike Shed
315: Emotions Are A Pendulum

The Bike Shed

Play Episode Listen Later Nov 9, 2021 41:23


Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. rspec-retry (https://github.com/NoRedInk/rspec-retry) Cassidy Williams - It Depends - GitHub Universe 2021 (https://www.youtube.com/watch?v=aMWh2uLO9OM) Say No To More Process (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) StandardRB (https://github.com/testdouble/standard) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: My new computer is due on the fourth. I'm so close. STEPH: On the fourth? CHRIS: On the fourth. STEPH: That's so exciting. CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer. STEPH: [laughs] CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles] STEPH: Take its soul. [laughs] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure. On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase. CHRIS: How long were you on this project for? STEPH: It'll be a total of I think eight months. CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things? STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I'm getting really comfortable with this new environment that I'm in. And so then I have that first month. And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team. CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project. STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project. Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it. But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch? CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it. I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file. So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that. That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI. And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there. STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this. CHRIS: I'm working here. [laughter] STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list. CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there. STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs] CHRIS: Yes. STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?" CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass." STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process. CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes. We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were. STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs] CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles] STEPH: [laughs] That was the second hot tip, and you got it. CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context. So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally. So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future. But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild. So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let's call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it. We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea. STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them. And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know? CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera? STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them? CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed. So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that. STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them? CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total. STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it's not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous. CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet. STEPH: I don't think so. CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken. And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter] STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve. So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this. But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes. CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles] STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off. And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before. It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial. And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it. CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is. STEPH: [laughs] CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit. And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that. Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production. And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness. And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently. STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize. The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through. But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself. CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us. And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine. But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind. Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic? STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral. CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be. STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information. CHRIS: Me too. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable. As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think? STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in. But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with. From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had. But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied. So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants. And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that. And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it's something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris? CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again. Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it's only a single commit in a PR for me. But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future. There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants. STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that. And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there's that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request. But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit. And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process. CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things. And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider. I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do. STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Enjoy the Vue
Episode 80: Opting into the Composition API with Oscar Spencer

Enjoy the Vue

Play Episode Listen Later Nov 8, 2021 66:27


With the release of Vue 3, developers now have access to the Composition API, a new way to write Vue components. This API allows features to be grouped together logically, rather than having to organize single-file components by function. Using the Composition API can lead to more readable code, and gives developers more flexibility and scalability when developing their applications, which signals a bright future for Vue. At least, this is what today's guest believes! Today, we speak with Oscar Spencer, developer at Tidelift and co-author of the Grain programming language, about Vue's Composition API and why he believes it represents great things for Vue. We touch on Options API, our opinions of a template-first approach, and why Composition API is infinitely better than Mixins, as well as how JavaScript can prepare developers for Options API and what to watch out for when you first start working with Composition API in Vue. All this plus this week's picks and so much more when you tune in today! Key Points From This Episode: An introduction to today's guest, Oscar Spencer. The panel shares what sound their Slack makes when they receive a new message. Oscar shares his personal passion for the Vue Composition API. Why he believes that Vue's bright future includes the options API too. Why Composition API represents great things for the future of Vue. The panel discusses commit messages, interactive rebasing, and squashing. What Oscar means when he says that the Composition API makes Vue more scalable. Oscar and the panel weigh in on taking a template-first approach  Discover Oscar's situational approach to composables when reusing business logic. Composition API versus Mixins and why Oscar believes Composition API is superior. Whether Options API or Composition API is easier to teach to a beginner developer. How JavaScript prepares developers for Options API, which Oscar describes as ‘cozy'. Oscar on how to know when to use Composition API versus Options API. Why you would choose Composition API over simply using JavaScript: reactivity. The panel shares some of the longest Vue components they have worked on. Render functions in Vue and Oscar's perspective on React versus Vue. What to look out for if you're new to Composition API; not understanding Vue's reactivity. Why the coolest thing Oscar has done in Vue is write a backend using the reactivity API. This week's picks: Only Murders in the Building, The Artful Escape, Dyson Sphere Program, The Great Ace Attorney Chronicles, and more! Tweetables: “When I look at the Composition API, I see a very bright future for Vue.” — @oscar_spen (https://twitter.com/oscar_spen) [0:02:22] “The Composition API just gets rid of a whole host of issues that you have with Mixins. In fact, Mixins were my only complaint in Vue 2.” — @oscar_spen (https://twitter.com/oscar_spen) [0:24:05] “Don't be too scared of the [Composition API]. It was definitely designed with composition in mind. It was designed for you to have your composables consuming composables and not blowing up the world – [while] being fairly easy to follow as well.” — @oscar_spen (https://twitter.com/oscar_spen) [0:27:34] “Regular JavaScript modules only get you so far because, fundamentally, what these regular JavaScript modules are missing is the reactivity. What the Composition API is letting us do is compose things that are reactive.” — @oscar_spen (https://twitter.com/oscar_spen) [0:41:44] “By far the biggest gotcha with the Composition API is not understanding Vue's reactivity. That's going to be the biggest gotcha that you can possibly run into. I highly recommend, instead of trying to wing it, just go look at a tutorial.” — @oscar_spen (https://twitter.com/oscar_spen) [0:57:02] Links Mentioned in Today's Episode: Vue-oxford (https://www.npmjs.com/package/vue-oxford) Unconventional Vue - Vue as a Backend Framework (https://www.vuemastery.com/conferences/vueconf-us-2020/unconventional-vue-vue-as-a-backend-framework), Oscar Spencer (VueConf US 2020) AITA for being mad at my parents for decorating my first house without my consent? (https://www.reddit.com/r/AmItheAsshole/comments/pmgu2h/aita_for_being_mad_at_my_parents_for_decorating), iamcag07 @oscar_spen (https://twitter.com/oscar_spen) (Twitter) ospencer (https://github.com/ospenser) (Github) Grain (https://grain-lang.org) Dyson Sphere Program (https://en.wikipedia.org/wiki/Dyson_Sphere_Program)  The Artful Escape (https://theartfulescape.com/) Only Murders in the Building (https://www.hulu.com/series/only-murders-in-the-building-ef31c7e1-cd0f-4e07-848d-1cbfedb50ddf), Hulu (Television Show) The Great Ace Attorney Chronicles (https://www.ace-attorney.com/great1-2), Capcom (Nintendo Switch, PlayStation 4, Steam) TERRO® Fly Magnet® Super Fly Roll (https://www.terro.com/terro-fly-magnet-super-fly-roll-t521) Tiny Beautiful Things: Advice on Love and Life from Dear Sugar (https://libro.fm/audiobooks/9780449808269-tiny-beautiful-things?bookstore=bookshoporg), Cheryl Strayed Special Guest: Oscar Spencer.

Founders of Web 3
Rapid DeFi, with Dean Tribble of Agoric

Founders of Web 3

Play Episode Listen Later Nov 8, 2021 34:04


Today we talk to Dean Tribble, founder of Agoric, a Proof-of-Stake chain utilizing secure JavaScript smart contracts to rapidly build and deploy DeFil, comprised of a team who are experts in smart contracts. Agoric was founded on open-source principles which look to build a public economy. During the episode, Dean and Jamie Burke discuss the importance of developer accessibility, composability as more than just a buzzword, moving on from flash and HTTP, scaling for DeFi, DAOs and NFTs utilising decentralised finance, and more!

CodeNewbie
S18:E1 - What are SVGs and when should you use them (Christina Gorton)

CodeNewbie

Play Episode Listen Later Nov 8, 2021 22:42


In this episode, we talk about Scalable Vector Graphics, or SVGs, with Christina Gorton, developer advocate at Forem. Christina talks about what an SVG is, and when might use SVGs over CSS or Javascript for your graphics or animations, and why using SVGs has grown in popularity in recent years. Show Links DevDiscuss (sponsor) DevNews (sponsor) New Relic (sponsor) Retool (sponsor) SVG freeCodeCamp HTML CSS JavaScript CodePen Pixel art Adobe illustrator Inkscape Figma WebGL CSS layout CSS Grid

No Plans to Merge
Caleb Keeps Buying Things (House, Fridge, M1)

No Plans to Merge

Play Episode Listen Later Nov 4, 2021 102:25


We're back. Everyone was awake at the agreed upon time. We talk about Caleb's house, The fridge. The facebook guys with trucks, the Macbooks and some Livewire and Alpine jazz

Edge of the Web - An SEO Podcast for Today's Digital Marketer
455 | Future-proofing Your Site-Speed with Victor Zhitomirsky

Edge of the Web - An SEO Podcast for Today's Digital Marketer

Play Episode Listen Later Nov 4, 2021 33:13


In our second segment of our Victor Zhitomirsky interview, we unpacked the caching and optimization tools available to help speed up your websites.  Understanding the part that JavaScript plays in the rendering speed is a must.  We dive into difference caching systems and hosting providers, arming you with an incredible set of options to future-proof your site speed.   [00:07:12] Caching and Optimization tools for your WordPress site [00:08:30] What to look for in optimization and Javascript delay tools [00:09:17] Branching Javascript loading is the future of the Wordpress ecosystem [00:10:44] Page build platforms: which are the heaviest JavaScript load? [00:14:30] Will speed be a ranking signal in the future? [00:16:12] The new ecosystem of page-builder tools & Google's reward. [00:17:59] If we can't rebuild, what should we be looking for in caching tools? [00:22:11] Caching is not caching anymore [00:25:35] Comparing hosting providers

Chit Chat Across the Pond
CCATP #703 – Bart Busschots on PBS 128 of X – JavaScript Module Basics

Chit Chat Across the Pond

Play Episode Listen Later Nov 3, 2021 87:59


This installment of Programming By Stealth could probably have been two segments but all of us are itching to get moving quickly so we decided to power through. In the first part of the installment, Bart introduces us to JavaScript modules by giving us a bit of a history lesson on how they've evolved. If you're brand new to modules, this will be interesting but not essential. If you have history with them though, you'll definitely need to pay close attention to understand what's changed. Then Bart gets into the details of how modules work. He explains how JavaScript modules export variables, functions, and classes and how there are named exports and default exports and how the syntax differs. What fun would learning about exports be if he didn't tell us how to import variables, functions and classes into our code for when we use these modules? We also learn about module specifiers to make it all go. Finally, Bart takes us through three worked examples where he creates some JavaScript modules that exercise everything we just learned. It's a long episode but as always, Bart's excellent show notes at pbs.bartificer.net

All JavaScript Podcasts by Devchat.tv
D3 and Data Visualization ft. Ian Johnson - JSJ 507

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Nov 2, 2021 59:21


Ian Johnson is a former Google UX engineer and data visualization engineer with ObservableHQ building data visualizations with JavaScript. He works on both the tools and the visualizations built with D3 on the web. He discusses how to use tools like D3 to tell a story using your data. Panel Dan ShappirSteve Edwards Guest Ian Johnson Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialDev Influencers Accelerator Links ObservableDrawing with DataScales / Observable PlotTwitter: Ian Johnson ( @enjalot ) Picks Dan- Apple's Browser Engine Ban Is Holding Back Web App Innovation – The New StackIan- Bret Victor, beast of burdenIan- For ExampleIan- Bret Victor - Inventing on Principle - YouTubeSteve- Dad Jokes on InstagramSteve- Dad Jokes by Pubity Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Ian Johnson.

JavaScript Jabber
D3 and Data Visualization ft. Ian Johnson - JSJ 507

JavaScript Jabber

Play Episode Listen Later Nov 2, 2021 59:21


Ian Johnson is a former Google UX engineer and data visualization engineer with ObservableHQ building data visualizations with JavaScript. He works on both the tools and the visualizations built with D3 on the web. He discusses how to use tools like D3 to tell a story using your data. Panel Dan ShappirSteve Edwards Guest Ian Johnson Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialDev Influencers Accelerator Links ObservableDrawing with DataScales / Observable PlotTwitter: Ian Johnson ( @enjalot ) Picks Dan- Apple's Browser Engine Ban Is Holding Back Web App Innovation – The New StackIan- Bret Victor, beast of burdenIan- For ExampleIan- Bret Victor - Inventing on Principle - YouTubeSteve- Dad Jokes on InstagramSteve- Dad Jokes by Pubity Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Ian Johnson.

Software Social
A Conversation with Kevin Sahin, Co-Founder of ScrapingBee

Software Social

Play Episode Listen Later Nov 2, 2021 56:25


Follow Kevin! https://twitter.com/SahinKevinCheck out ScrapingBee: https://www.scrapingbee.com/AUTOMATED TRANSCRIPTColleen Schnettler  0:00  This episode of Software Social is sponsored by Hey Check It. Does your website performance keep you up at night? The creators behind Hey Check It started it for this very reason—peace of mind about their sites and the sites they manage. Hey Check It is a website performance monitoring and suggestion tool focused on SEO, accessibility, uptime, site speed and content. It includes AI-generated SEO, data, spelling and grammar checking, custom sitemaps, and a number of other tools. If you're managing multiple websites, check their agency plans with public facing dashboards to meet your clients' needs. Start a free trial today at HeyCheckIt.comMichele Hansen  0:39  Hey, welcome back to Software Social. We're doing another interview this week. I am so excited to have Kevin Sahin with me. He is co-founder of ScrapingBee. Kevin, welcome to software social.Kevin Sahin  0:57  Well, thank you, Michele, I'm excited to be here.Michele Hansen  1:01  So this kind of came about because I was on Twitter, as I often am. And I noticed, I think it was actually someone tweeted about MicroConf Europe, which I had been really wanting to go to, but conflicted with a friend's wedding. So we couldn't go. So I was just sort of following and watching everything unfold on Twitter and tweeted about how peer your co founder was, was giving a talk. And he mentioned how scraping DEA offered free API credits to customers who are willing to jump on a 15 minute call with them. And you guys ask them questions like, what else have you tried, and my interest immediately perked up. And really wanted to talk to you about those calls you had and what you learned from them, and what that added for the business. But before we jump into that, perhaps you should say for a moment, just what scraping be. Is and, and whatnot. And?Kevin Sahin  2:09  Sure. So um, so basically scraping the is an API for web scraping. When you are extracting data from the web, you often have the two same problems, which are, there are more and more websites that are using JavaScript frameworks like Vue js, react, etc. And so you have to render the page inside a web browser. And this is kind of, it's a pain to manage, especially at scale. Because you have to, you know, there are lots of DevOps skills that you need. You need big servers, you need lots of things. And it's really handy to have, you know, a headless browser accessible with a simple API call. The other thing that you have to do when you scrape the web at scale, is to manage proxies. So you can you probably need proxies for many different reasons. For example, let's say that you are extracting data from ecommerce website. Well, most ecommerce websites are internationalized, meaning that if you access the website from an IP address in Europe, you will have the prices in euro if you access the IP address or the website from an IP address in the US you will have prices in dollars. So you need some kind of proxy management system. The other thing is IP rate limit. Some websites are limiting the number of pages you can access per day from a single IP address if you need to access more pages, you need more IP addresses etc, etc. And so we bundled this inside a single API which is scrapingMichele Hansen  4:04  so I love how you're solving that because we have felt that pain personally. So I've kind of talked a little bit in the past about how my husband dies first project that was what so the one well, not at first, but the one right before geocoder that basically funded Juco was this mobile app called what's open nearby where you could open it up and see grocery stores convenience stores and coffee shops that were open near you. And how we ran that in the back end was we had a ton of scrapers running of like grocery store, you know Starbucks, whatever like their websites, scraping the hours off of them and we like just all the time there's issues you know, the parsers breaking or you get blocked or actually the the sort of recent side project we did Keren, which allowed people to get an alert when a grocery pick slot opened up on a on a grocery stores website because of COVID and everything that was also powered by scrapers basically and the back end. And so I have I have personally felt the pain of, you know, the impacts when when when, you know, scraping goes wrong or you know it can get frustrating at times.Kevin Sahin  5:29  Yeah, that's I mean, there are the, the story behind scraping is that we, we personally experienced some of those frustrations, because p&i like before launching scraping beam, we started our career in two different startups that were heavily relying on web scraping. In the business, I was working on a startup in France, which is kind of a mix between mint.com in the US and plaid.com. So for those who don't know, it's a bank account aggregation software's sublet, that comm is an API that allows third party to access your bank account. And means that comm is a bank account aggregation, personal finance management app. And so at this startup, I was really exposed to all of these issues. And Param, he was working for a real estate startup, a real estate data startup in France. And so there will relying on scraping lots of real estate portals. So we both, you know, experienced lots of these issues regarding how to handle headless browsers, how to handle proxies, how to, you know, handle blocks, etc, etc. So that was something we, we knew a little about,Michele Hansen  7:16  I love how you started with a pain that you had. But also as, as you've run the business, you're also actively reaching out to your customers to understand what they were trying to do, what problems they were having, and how they were solving those problems. So I wonder if you can kind of take us back to when you like, how did those emails come about where you were reaching out to people like, like, what what kind of prompted that?Kevin Sahin  7:47  Yeah. So that we quickly realized that we really knew when I say that we knew a little about it, it's not an a few million. Because we really knew a little about the different web scraping use cases each time. I mean, from the beginning, when we launched the API we like from day one, I'd say, we realized that some users, we're scraping, have had some use cases that we never imagined. So we quickly realized that we had to get them on the phone and knew more about about it, understand their businesses, what kind of data they they needed, what frequency for what we use case, etc, etc. But the problem that we had is that at the beginning, so we had we had the banner on the dashboard, covering that, if they had any question, they could schedule a call with me. But nobody was scheduling any call. So maybe, maybe the banner was wasn't, I mean, the copy wasn't great, maybe. The CTA wasn't clear, I don't know. But the fact is, nobody was getting any call with me. And we also had an email sequence where we, we had a few links to my county. But it wasn't working. I mean, sometimes we had a trial scheduling a call, but it was not very, not a lot. And and then we we had this idea of offering more 10x more free API calls. Then the trial offered. And then instantly, we started to get a lot of calls. So many that I had to, you know, delete some availability in my week, because I was just doing calls every day all day. And, and it was great because we will learn so much we, I mean, we will learn so many different use cases that we never thought about. For example, I don't know, we, we, we had so many diverse people. So for example, university researchers that were scraping the web for all kinds of research projects. We had government agencies that were scraping the web, to automate automatically detect security frauds. That's all those kinds of use cases we could never invented them, we like, I don't see any other way we could have learned all of this, then, you know, calling our customers and, and developing a relationship with them. And by the way, this, I mean, there are many benefits to these calls. It's not just about, you know, discovering their needs, but it's also building relationships, especially when you are one month old startup. Because, you know, it's really hard to sell your product, especially with enterprise customers, you know, government agencies, universities, etc, etc. When you say, yeah, we were launched a month ago, there's a bit of a trust issue. And developing the relationship, a relationship with them, really helped. Like, in the seven months, after our launch, we signed a big enterprise customer. And I think that we never could have done this without, you know,having them on the call. It also helped in many other ways. For example, I mentioned the the, the university researchers, we granted them free credits to the API for their research project. And like a few weeks or months later, they mentioned us in the University website, which is great for many reason for SEO for authority, etc, etc. So, I mean, there was like, it took me a lot of time to take these calls, but the, the benefits is a like, it's really worth it. And I'm glad we did.Michele Hansen  13:44  It's so interesting how you say that you You not only learn so much about why people need something like scraping be in the first place. But it also built this trust with your customers when you're very you're very new company, and they really didn't have a lot of reason to to trust you. And even though the purpose of them maybe was not, you know, making these sales, it really led to them down the road. All because you took 15 minutes to understand what they were trying to do and what they had been using before.Kevin Sahin  14:23  Yeah. Most of the time, it was more than 15 minutes, by the way. Like, especially when the conversation was getting technical. Because even those scraping visas, simple REST API, there's a whole you know that they often needed. Advice advices about how to implement it on their side. Meaning how to you know Do the scraping pipeline, the scheduling, the data storage, the error monitoring, the maintenance of the scrapers how to what kind of libraries they could use, etc, etc. So I, we we spent a lot of time with this. Sometimes this was a bit too much like, for example, when you spend one hour advising the technical team of your prospect and that that at the end, they don't end up being a customer. It's a bit frustrating. But at the same time, it was really I mean, it was a as a two months old startup, it's a really competitive advantage, I'd say that to be able to take the time to really advise and guide the prospect in the implementation. So and it really helped us to sign the first customers.Michele Hansen  16:24  I'm curious, do you remember the exact questions that you asked people?Kevin Sahin  16:30  Yes, I remember. It's not. I didn't ask a lot. But I was asking them about their, what their company is doing. What? Why they want to scrape data? I mean, is it part? Is it something that is part of their core product core business? Or is it some side thing? The, the the kind of website that they needed to extract data from the frequency? And why like, what did they tried so far? Why did it didn't it worked? Why are your other looking for another solution? Etc, etc. So that, like these five questions, or the most important one, I thinkMichele Hansen  17:35  it sounds like those questions came out of your own genuine curiosity, because you had some awareness of the some some things people might do with scraping from your own experiences. But you were aware that that was not the whole universe of things that people might possibly do. And so you genuinely did not know what the other things people why people might be doing it and what else they might be doing.Kevin Sahin  18:03  Yeah, exactly. And, and we were pretty lucky to realize this early. Because, you know, you're always tempted to just see things through your own experience. But we, as I said, early on, we, we realized all those kind of use cases we had no idea about. And so we got pretty curious about it pretty early.Michele Hansen  18:43  And in so many ways, that reminds me of how I got interested in customer research in the beginning, too, because when we launched geocode, do you know it? I mean, so it came out of our own needs, actually, because that that app I mentioned finding grocery store hours, it would show people a map, and we needed coordinates in order to show that map. And, and so it came out of our own need there. But we're not, you know, neither of us has a background in geography or geographic data analysis, GIS, any of that stuff. And when we launched and people were, you know, reaching out to us, and they're asking for us to do things, we would ask them why because we genuinely did not know because we were not do geographic information systems, people. We weren't steeped in this world. So it was as much about how do we expand our product? As you know, but what why do you want to do it in the first place? Because I just I just don't know. And following that curiosity, yeah.Kevin Sahin  19:48  And so um, the geocode IO, you launched this how many years ago,Michele Hansen  19:58  we launched in January of 2014. So we are Coming up on eight years this January. Wow, congrats. almost a decade of, you know, a couple more years. But yeah, it's kind of wild. snuck up on me.Kevin Sahin  20:17  That's a that's cool. And so how did you when you launched in 2014? What, how did you get your first customers.Michele Hansen  20:34  So we were our first customer for that app, because the app was making about like three or $400 a month in ad revenue. And basically, the idea of do codea was that, you know, we could basically if we released it as an API and threw a wall in front of it, maybe other people would pay to keep the server's going for it. And then we would, we could still keep our app going, and then not basically not be paying for for this geocoding API, rather than paying you know, a major provider, you know, 10s of 1000s of dollars a year, which we didn't. So we had, you know, two little digitalocean droplets that it was running on for 20 bucks a month. And that was our goal was to make 20 bucks a month. So we then, you know, put it on, you know, we talked talked to some other friends who are developers and had them test it out, and then put it on Hacker News. And that was how we got that initial wave of feedback, we had 1000s of signups. Most I mean, that traffic doesn't stick around, like, you look at analytics graph, and it's just like, you just we basically have to filter out our launch, because it's just, it totally breaks the graph. And but we made, we ended up making $31 that month, that that first month,Kevin Sahin  21:55  sorry, trade paid for the Digital Ocean droplet,Michele Hansen  21:59  we were over the moon, because we had made more money than we spent on it. And to us, that was a wild success.Kevin Sahin  22:10  And so how did you like, after this initial hack on your success? How did you continue to, you know, acquire customers and develop the company.Michele Hansen  22:25  So I think in the early days, it was a lot of, you know, when people expressed that they had problems that we solved, trying to be there, so I spent hours, you know, replying to stuff on Stack Overflow. And, you know, whenever something came up on Hacker News, someone asking about geocoding, whatever, we would always like pop in there, or on Twitter, or just kind of trying to be in the places where people were already looking for something like this. Of course, we had we had a website, but I don't, it wasn't super built out, you know, with, you know, case studies and example customers and testimonials and, you know, stuff like that, basically, it's for like documentation for for a long time. But um, yeah, I basically spent a lot of time on StackOverflow trying to sort of, you know, neutrally, like reply to questions and kind of, yeah, keep people coming to us,Kevin Sahin  23:33  and how, like, how did he did evolve? Like, right now, where, where does your customer are coming from?Michele Hansen  23:43  That's a really good question. Because I don't always know. We don't do a ton with analytics. But pretty much we're very SEO based. So it's still that idea that someone is already frustrated. They're already trying to find something for geocoding. Or for you know, they need you need mentioned academic researchers. So we have a lot of customers who are academic researchers, because in the US, in order to connect to any government datasets, you need this thing called a FIPS code. And you can only get that FIPS code if you have the coordinates for the address. And then the government data will be at that FIPS code level, which is basically sort of like the block. So for example, if a researcher is they know they need FIPS codes to connect to some data, there'll be googling it and so is to have tons and tons of landing pages showing people how you need to convert addresses to FIPS codes. Here's how you can do with our API. Here's how you can upload a spreadsheet. You know, if you need congressional districts, here's how you can do it. If you need time zones, here's how you can do it. And it's very content driven. On the SEO side, we we still do a little bit of replying to stuff on StackOverflow I don't think I've done that for months if not, you know like not really Really anymore? Um, pretty much it's it's about, you know, being there when someone is already looking for something.Kevin Sahin  25:08  No, we that's something that we, we also did in the beginning of scraping be. We answered Korra questions, not a lot, not a lot of Stack Overflow but a little bit, and then on forums on Twitter and indie hackers, etc, etc. And just like you like now most of our customers are coming from SEO, I'd say 90%. And we've been really focusing on that, since the beginning, we launched the blog, and even before the product was launched, so I think that our first blog was in May 2019. And we launched in August 2019. So you really treated SEO as a, like our main acquisition channel,Michele Hansen  26:17  and seems like you guys are, I don't know if you're quite like freemium. But you I noticed on your site that it says you can get started with 1000, free API calls, no credit card required. You know, in many ways, I feel like, you know, I think I think it's, you know, freemium is not a pricing model. It's a marketing tactic. And I very much feel like, you know, that combination of SEO and freemium is a huge part of why we have been able to attract customers, because people can try it out without, you know, without having to talk to us first, they can see if this is the product they need, and then they're like, okay, like, we're ready to ready to sign up, and you don't feel like you don't have to sell as hard when you have that combination of SEO and freemium, because people can just figure out for themselves if it's what they need.Kevin Sahin  27:22  Yeah, exactly. And there is only one thing that is very specific to API's. It's that in many companies, and so I learned this with the customer interviews, the developers do not necessarily have access to the company credit cards. And having a free trial without credit card is really something that can boost the activation. Because if the developer has to ask is n plus one or n plus two for a credit card? And maybe he's like, it's going to bother the developer, he's not even going to try the service, or it's going to slow things down because he needs the approval, etc. So having the free credits on the trial is really something that helped us. And I don't I don't see any, I mean, I see many drawbacks of not having it. I don't see many benefits of having, you know, a credit card. They will follow the trail when you're doing when you have an API business.Michele Hansen  28:45  Yeah, exactly. And then you know, the developers they can they're trying to get their work done. They can try it out for themselves, see if it works. And then if it is something that's going to work for them, then like they're the one selling your product within the company. You don't have to be emailing all the CTOs and directors and everything being like, Hello, we're scraping me and this is what we do. Like, it's already there. Developers within the company who are like, hey, like, we've got this project. We've got this deadline, I need to use this thing. I already tried it. It works like can you like, like, yeah, give me the card. Let's go. Let's get this over with. Exactly. Yeah. And I'm curious when you did those calls, you said you gave them free API credits? How many did you give them for those calls?Kevin Sahin  29:28  How many API credits Yeah, I mean, it was at least 10,000 acre grades, sometimes even more, depending on there. So the thing you have to keep in mind is that one API creates isn't equal to one API call. Because the the cost of the API call is depending on the parameters that you use with your API call, and it can cost up to 25 API credits per call, so it goes up quickly.Michele Hansen  29:59  Yeah. So but so basically, I'm just wondering what the, the cost to that, uh, you know, there's the cost of those interviews, but also basically like, you know, because sometimes, you know, often recommend if you're doing call somebody know, give them a 10 or $25. Amazon gift card, and I'm just kind of curious like what thatKevin Sahin  30:20  wasn't? It was not much, I'd say, but I don't have a precise figure to give you I don't know, but probably less than $1 per per 10,000. I mean, they don't even they don't like most of them didn't use the whole 10,000 free credit. So I don't think but not much. So theseMichele Hansen  30:48  customer interviews cost you maybe less than $1. Yeah, each, which actually wasn't a cash outlay, because you're just giving them credits. Half an hour, maybe an hour of your time, depending on how technical their questions were. But down the line could lead to these enterprise sales. And the customers really trusting you in a way that they maybe would not have had you not spent this time and given them those credits.Kevin Sahin  31:19  Yeah, I can't even give you a precise numbers. The first month in August 2019, we signed our first enterprise customer for seven or $800, a month after one of those calls.Michele Hansen  31:37  Wow. Do you know how many of these calls you did? You mean, you mentioned you to them over 18 months? But I'm curious if you have aKevin Sahin  31:44  I did a lot in the beginning, I'd say probably 200, something like that.Michele Hansen  31:55  And I'm curious, you know, you said you you did this for? Like, are you still doing these calls? Or?Kevin Sahin  32:01  I am but so right now, we don't offer free credits anymore. We just have some links in our email sequences. And on the website. If for the trial, period, when customers have questions that cannot be answered, with our knowledge base or recommendation. And now I would say that maybe I have four or five calls per week. Maximum.Michele Hansen  32:38  Yeah, that's, that's awesome. Yeah, I'm still sort of, you know, the the calls came about because you were just you were curious about why does anyone need this thing we made this very similar to us. And I'm curious of, you know, as as, as you were, maybe thinking about doing that, like, like, the questions you asked, you know, are very much, you know, sort of quintessential jobs to be done questions. And I'm curious, what kind of understanding you had of customer research. Before you started doing this?Kevin Sahin  33:25  I would say zero.Michele Hansen  33:30  facet came out organically.Kevin Sahin  33:33  Yeah. I mean, no, I, like, I probably read a few blog posts about how to do customer interviews. It's just not like it was a, you know, a bit of both customer interviews and sales call. So but I mean, I'm not I'm not a salesperson. I don't, I was just, you know, trying to see if, what the customer problems were and if scraping me was a good fit to solve these problems. And if it was, then I would honestly, tell them told them that I thought scripting was the best solution for them. And if it wasn't, then I just told them to. I mean, actually, I told them what if scripting wasn't the solution, I often told them what the solution was. So if I had to refer them to a specific software or consultant or whatever, I did it. And yeah, dog came, I'd say, semi organically. I had some notions about the customer. interviews and sales gold that no experience at all.Michele Hansen  35:05  Fascinating you just kind of dove like head, you know, sort of headfirst into it. And I mean, it seems like it's really helped your your business and help you understand like, like why people need scraping and how you can help them and lead to these enterprise customers and you guys are in tiny seed likeKevin Sahin  35:30  yeah, definitely it really helped.Michele Hansen  35:33  That's awesome. Cool. So I'm curious, you had mentioned that you also had some questions about geocoding. And I wanted to make sure we got time to get Yeah, soKevin Sahin  35:45  So I'm curious about the letter. So first of all, where are you based?Michele Hansen  35:50  So we are in Denmark now. But when we launched geocode, do we live? Actually, we lived in Washington, DC. We lived in Arlington, Virginia, which is just outside DC until July of 2020. So so now we're in Denmark.Kevin Sahin  36:07  Alright, that's cool. And yeah, so the question I had is, you know, the usual what, what led you to? to geocode? So you've answered this a little bit, but what what were you doing before? How did you find the date? You know, did you did some consulting on the side? Was it a side project, etc, etc. Found the stories, always fascinating.Michele Hansen  36:37  Yeah, so um, so I kind of mentioned a little bit. So we had this mobile app, which is making a couple 100 bucks a month in ad revenue. This is like 2012 2013. And we need a geocoding for it. And we ran into a point where we basically couldn't use Google anymore, because they didn't have pay as you go at the time, it was either 2500 for free per day, or enterprise contract, and we just needed 5000. So we had to, basically sort of rolled our own geo coder that was very rudimentary. And we kind of talked about this problem that we had, you know, not being able to store the data and whatnot. And, you know, developer friends had the same problem, made an API, put it on Hacker News, $31, the first month kind of vary, and got tons of feedback from people ask them, you know, why they wanted to do what they needed to do. So started, you know, adding those features as people needed them, like a big thing for us early on was was the ability to upload a spreadsheet. And I think we made our first sort of, you know, higher end sale, May of 2014. So a couple months after, and that was, I mean, that wasn't really adding that that we called the unlimited plan, which at the time was 750 a month was huge part of our growth. But so from that, the beginning as a side project, and it stayed a side project until I went full time, which is October of 2017. So currently celebrating my four year full time anniversary. I was I was a product manager before Okay, yeah, yeah, I was I was specifically like in Well, I was a first I was an operations manager that I was a technical project manager do work managing like WordPress website, builds that agency. And then I really wanted to to like dig my teeth into things. So I transitioned into being a product manager, which led into then doing product development, which is sort of where my heart is, which is how I got into customer research to is doing product development and launching a lot of stuff that didn't work out just like learning that you really need to talk to prospects and if you want something to succeed, learn that the hard way. me so I went full time 2017 and then my husband he and we're like, oh, you know, if I go full time, like it's gonna you know, maybe take some of the load off and make things a little easier. Except you know, I was full time so then our response to our customer response times got better, you know, and we actually grew more and so we're like, Okay, well now husband needs to go full time. And this is February of 2018. And he went to his boss and was like, you know, it's time for me to go full time on this thing. And his boss was like, No, and we're like, this is an interesting negotiating position to be in so he ended up going part time part salary but keeping health insurance which in the US is huge. And, but he eventually went full time by September of 2018, because I mean, basically the more we worked on it, the more you know, the better the product. Got. Yeah. And?Kevin Sahin  40:02  And yeah, did you? Do you have any employees?Michele Hansen  40:08  No, I have a VA, but we don't have any employees.Kevin Sahin  40:12  Okay, so you are very lean? Yeah, yeah, weMichele Hansen  40:15  we focus a lot on, you know, automating as many things as we can. And I think that's one reason, you know, we talking earlier about, you know, SEO and free tier and not having to, you know, sort of, you know, do cold outreach and reach out to companies. You know, partly it's because, you know, that's kind of the sort of workflow I like, when I'm starting up with a product, I like to be able to test it out, see if it works, not have to talk to anybody, like I hate when I have to have a demo to figure out if something is what I needed to do. But also, because we just don't have the time to be, you know, reaching out to people and pitching them, because it's just the two of us, but and that's also, like, a conscious decision on our part, like, we could hire another rep, or we could hire, you know, a salesperson or whatever. But we also just, we, we kind of like how calm it is with just the two of us. So SoKevin Sahin  41:06  you said, Yeah, so basically, you plan to stay just the two of you and not hire in the future.Michele Hansen  41:15  Yeah, that's the plan.Kevin Sahin  41:17  Okay. That's, I mean, there are many founders that, like, this situation that don't really like to manage employees, etc, etc. So that's great, that's working for you.Michele Hansen  41:37  I'm a very, I'm just very product driven. Like, that's what I really love doing is, is product work. And I also I do enjoy, like, sales work, too. So like my time, you know, my sort of favorite things to work on are both product and, you know, customer research and whatnot. And then also doing, like sales and negotiations. And, and yeah, if we had employees, you know, I would be spending time managing employees. And I just, I don't know, I just that that's just not really where my, my heart is. It's not in being a manager, it definitely is for some people. ButKevin Sahin  42:20  yeah, I can relate toMichele Hansen  42:21  that. Yeah.Kevin Sahin  42:25  Yeah, that's, I mean, that's, I don't have much experience managing employees. But for our blog, I worked with a lot of freelancers, you know, different kind of freelancers, constants, writers, editors, some Freelancer to help me with the SEO link builders, etc, etc. And I mean, it's really hard to hire, to manage to keep employees motivated. I mean, it's, it's pretty hard.Michele Hansen  43:10  Yeah, it's a lot of time. And, you know, I think from my own experiences, and you know, those of you know, people I know, like, having a manager who doesn't love being a manager, who, you know, doesn't love, like developing people, and helping them grow, and all that kind of stuff, like, there are people who genuinely love that those people should be managers, those of us who, you know, are a little bit more reluctant on it and enjoy other things. I think it's okay, if we allow ourselves to, to not be managers. And, you know, I sometimes think that there's this, this assumption that, that, that you have to grow and that you have to hire in order to grow. Is this sort of this baked in assumption, and I think there's a little bit of like, judgment sometimes around companies that don't hire because people like, oh, like, you're not a real company, if you don't have any employees or whatnot. I reject that. Like, I think if you can find a way to run a company, and it's successful and gives you the life you want, and for some people that involves employees, and some people it doesn't, and that's Yeah, exactly. And some people you know, it involves, like, I think, I guess, you know, my, my VA is is is you know, a contractor, like a lot of people have a lot of contractors working with them. But you know, having that responsibility also of covering someone's paycheck can, you know, can lend a lot of stress to running a business and some people like that stress and some people don't and I don't understand that like that. Yeah, I think that that sort of leadership component of it is is challenging and I sort of, you know, I asked myself, like whether I feel like at some point I could want to be a leader like that with employees. But quite frankly, I don't feel ready. You know, maybe in another season of life, I will be but at this point, you know, yeah.Kevin Sahin  45:25  Yeah. I mean, I, as I say, I totally relate to this, because it's, I mean, for me personally, I don't I don't think I totally agree with you with the fact that there is this assumption of growth and hiring and, and even sometimes raising funds, like, you have to you have to grow, you have to raise fund you have to hire, it's kind of, you know, a vanity metric in the startup ecosystem, how many employees do you have? To try etc. And, I mean, many companies that I mean, either don't hire at all or hire just, you know, a really small team, and that are doing totally fine, where the founders are happy, the employees are happy, everyone's happy. And, yeah, it's. And on the other side, there are many companies raising funds, hiring, and growing like crazy, whether founders are not happy at all, and stressed andMichele Hansen  46:43  yeah, I think, you know, that's something we, as founders, we have the decision to run our businesses in a way that, you know, to design the business. Right. And, and, you know, and for me, part of, you know, designing that business is it's, you know, setting it up in a way that, that we're running it in a way that we enjoy, and we enjoy working together. And it sounds like you and I really like working together, too.Kevin Sahin  47:12  Yeah. I mean, we've been, we've been, so we know each other since high school. So we, we've been working on many project, back in high school, and then side projects in college and the beginning of our career together. So yeah, it's been. And that's was the, it was great, because when we founded the company, we had this whole history of working together, of knowing how to talk to each other to, you know, divide the work based on, you know, what we are good at what we'd like to do, etc, etc. So it was pretty, I'd say, you know, a fluid, the work relationship.Michele Hansen  48:09  Sounds like you learned a lot from that that first side project you did together with him about how you can work together. I'm curious what that project was.Kevin Sahin  48:19  There were many projects, I'd say the most. The biggest one with a Chrome extension that we launched. I don't remember the year 2016, I'd say or 17. It was called shop tourist, it was a Chrome extension that could where users could save products on ecommerce websites that they were interested to buy. And our we had some scrapers in the backend that would refresh the price every day. And if the price dropped it send an email with a note with the with an alert that said, Hey, this product dropped 25% this night. You can buy it here. And then there was some affiliated links on the email. And like, we, we had some pretty good success marketing it on Reddit. Like we launched the we posted a Reddit post one day and it got 1000s of upvotes. And we like to overnight we got a few 1000 users on the app. And yeah, and the funny thing is that we realized Is that some customers? No, it was not customers, some users sorry. were added adding hundreds of products on their list. And we, we told ourselves, it's kind of strange, because why would I mean, unless it's, you know, the person is on the buying spree or is a has a buying problem. It's kind of weird to save, you know, hundreds of products with different variations of the same. I don't know, a T shirt or whatever. And so we realized that it was ecommerce owners that were monitoring their competitors, with our app, and they were doing it because our app was free. There were some b2b SaaS that were doing it, but it was very expensive. And so we saw an opportunity there. And we launched our first real company, pricing, but and it was a price monitoring app for ecommerce owner. And we did this in 2018. And it was a failure, we managed to get it from zero to 500, or 1000, in monthly recurring revenue. But we failed to grow it from there. And we knew nothing about marketing to ecommerce owners, or to ecommerce in general, except the previous experience we had with this little side project. And so we, we managed to sell it to one of the biggest player in this field, which which is priced to spy.com. And it's funded, what would become scraping be later. And the great thing about this failure is that with pricing, but we we had to scrape a lot of websites. So no, we had these those problems about JavaScript rendering, headless browsers, proxies, etc. So we like, we knew exactly that one, like this one kind of use case for scraping me.Michele Hansen  52:48  So interesting. And I feel like I hear so many similarities in our stories, but something that stands out to me not only how you were, you were able, you know that so that pricing bot, you know, ostensibly failed. But you were able to carry through that expertise you built in building scrapers, and understanding how difficult that can be and the problems with that. But what also carried through is I'm struck by how it seems you have this curiosity about user behavior. And you know, people were doing something and you're and you're like, Oh, that's interesting, why are they adding hundreds of products all of a sudden, and you allowed yourself to follow that, and I think that's such, like, such a great quality, and a founder to not only notice when something is strange, you know, but but follow it, you know, you could have shut your brain off that like, Oh, these people probably just have a spending problem and basically judge, right? And you could have just sort of left it at that. But instead of stopping at judgment, you instead be like, I wonder why they're doing it and follow that thread, you know, follow this sort of cookie crumbs and figure it out. Oh, it's because they're doing this ecommerce thing. Okay, well, maybe we can like pivot into doing that and then it didn't really work out but you got acquired and then you're able to use that funds to start scraping be but you had that understanding of your own use cases for scraping. And again, you were like, Why do people need this? Let me go figure it out. And you just allow yourself to follow that curiosity. And I I just love that.Kevin Sahin  54:33  Yeah, I mean, that was um, it was really a great experience. I mean, the the like, even though it was hard, you know, to fail, and both p&i we didn't. Like we had to fund the business ourselves. So it was a very hard Financially but the experience the learnings were really worth it.Michele Hansen  55:06  Yeah. It sounds like it. I feel like I could talk to you all day about this. This has been so much fun. Um, thank you so much for for coming on. I I know from this conversation that this is not going to be the last time I talked to you. So So this has been really enjoyable.Kevin Sahin  55:33  Thank you. Yeah, same for me. Thank you a lot. And maybe see you next time. I still have many questions around the geo coder, yo. And I'd like to, I'd love to talk more about it.Michele Hansen  55:52  Yeah. Hey, I'm always always happy to talk about your cardio. Cool. So if people want to know more about you keep up with what you're doing on Skype and BMI and whatnot. Where should they go?Kevin Sahin  56:03  They can go to my Twitter. It's @SahinKevin. And yeah.Michele Hansen  56:12  Awesome. Well, if you enjoyed listening to this episode, please like Kevin, and I know. And you can find us on Twitter at @softwaresocpod. Thanks. Thanks, Michele.

Syntax - Tasty Web Development Treats
Horror Web Dev Stories - 2021

Syntax - Tasty Web Development Treats

Play Episode Listen Later Oct 27, 2021 51:02


For episode 400, Scott and Wes talk about web dev horror stories - 2021 edition! LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Mux - Sponsor Mux Video is an API-first platform that makes it easy for any developer to build beautiful video. Powered by data and designed by video experts, your video will work perfectly on every device, every time. Mux Video handles storage, encoding, and delivery so you can focus on building your product. Live streaming is just as easy and Mux will scale with you as you grow, whether you're serving a few dozen streams or a few million. Visit mux.com/syntax. Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. Show Notes 02:54 - Hi guys, love the show. I wanted to share with you something that happened just the other day (Oct 4th), I was starting my new job today at a large tech company. They use React for everything (even DNS!, don't ask me how, it's complicated). I figured I'd celebrate my first day and push some code to prod, (how hard could useEffect be right?) Next thing you know, they ended up bringing in a guy with an angle grinder to get access to the server cage. 04:15 - No one from Denver can buy 06:38 - Bug accidentally gives $90 million to users https://www.cnbc.com/2021/10/01/defi-protocol-compound-mistakenly-gives-away-millions-to-users.html 08:34 - Share Pointy Knives Hi! I'm a developer at a consulting firm in Sweden, writing C# on the backend and using React with either JavaScript or TypeScript and hosting things in Azure 99% of the time (and 1% in SharePoint). I was in my last week at my last job before I was due to start my new job. Worked 12 h/day to keep up with all the handovers etc. to colleagues so they would have a chance to continue working on the solutions I have taken care of. One project was a process tool hosted in SharePoint Online. The guy who would oversee it had -1% experience with SharePoint (which I pointed out to my bosses). But to make things a bit easier, I wrote a deploy script to ease things a bit. Starts the terminal and runs the script towards the acceptance environment. Umpteen million errors appear… Which is strange, because there would only be about 20 commands (which can cause errors like these). I log into the environment to double check if I now accidentally entered the wrong values in the script (which looked okay according to me). But I get a 404 error when I try to reach the environment… I log into the admin interface; I discover that the site is gone… Also checking the trash can, there are no things there. Very strange. I find that I'm in a different folder than the one where I saved my script… In that folder there is an old deploy script that was used when the project was started a thousand years ago (which was not used after the project was “finished”). The first thing the script does is force delete the site and then try to create a new empty site… The site is gone with lists and everything (lists are a SharePoint thing, think of it as sql-lite), there are no backups of the acceptance environment (although it is very important). I just feel a little panicked about how I'm going to solve this. However, I remember testing a tool six months ago to copy entire environments. Where the first attempt was made on the acceptance environment. Finds the cloned environment and can use the same tool to clone it back. It took only 8-12 hours of work to create all the new things done in the environment in the last 6 months instead of X number of hours to build everything from scratch. Once I updated a feature that saves accessories on orders (same solution). However, I failed to add all the new fields to the production environment. Which meant that accessories were not saved at all… Which was discovered after a week… I fixed the error in 5 minutes and the sellers had to contact x number of customers to double check what kind of accessories they would have for their orders… 11:22 - External HD One time I needed to format a server. It was an outdated Windows server. I selected all the files and copied and pasted to an external hard drive. My drive was pretty fast and it took like a minute. I was like: “Wow! That's a great external hd”. Formatted the server and, as soon as I realized it didn't copy 10% of the files, I had that face. We all know that face. Anyways. Tried to restore the files using some HD recovery tools but they were all corrupted, not by the formatting itself but for the installation of the new OS. My boss was pissed! I was very young so I blame it on the server. I'm not proud of it. But why the heck they would ask a developer to format a server in the first place? By the way, my birthday is on Halloween. Spoooky. 13:07 - Hey Loser I was testing new code to automate mass-mailings to our customers. Who knows what demon drove me but I wrote the “test” mailings like ransom notes: “Dear loser! Fork over all your $$$ or else!” Well, all was looking great and I wa s feeling pretty pleased with myself. Progress bars were sliding and counters were spinning. But I could hear a rising commotion from the marketing guys behind me. Phones ringing, voices raised. Turns out I had moronically wired myself to the production database! Even worse for me, I'd only been at the company a month or two. I thought my goose was cooked and the Big Boss was plenty mad, but I owned up right away and apologized. We put out a cover story that we'd been hacked and all was forgiven. 15:01 - HE HATE ME I was part of the developer team that accidentally leaked the 8 cities the XFL, an alternate football league, a week before their press conference. ewrestling.com/article/wwe-ac… We were using Contentful and Gatsby. A junior dev entered the information into the prod space instead of the UAT space and when we released some bug fixes, it picked up the contact us content update. I found out after seeing stories pop up in Google News when I was about to go to sleep. Was taking the content down when we started getting calls from the CIO of the WWE. The league went bust because of COVID. 19:23 - I Don't Have Memory of This I had two pretty bad code changes that only showed their problems when they went live in production. Around 6 years ago, I was running into a large performance issue with some of our queries running slowly against this giant DB. We were using JPA/Hibernate and we had a bunch of joins that were done lazily. I switched a few of them to eager so that they would create a single SQL statement instead of a bunch (or thousands). The change worked fine on my dev environment, QA, and staging. Staging was supposed to be representative of production. So we went live and within minutes the entire system went down because of out of memory errors. We quickly switched back to the lazy joins. We found out that staging had more memory and fewer DB records than production though they were supposed to be exactly the same. 21:05 - Your Performance is Slowing us down Back when VMWare was becoming a thing, like 2010 or so. I was working at an ecomm site and we were seeing slow performance between the app server and some data services. I decided to build a little multithreaded logger that could track when a query to Oracle Financials was running too slow and generate a warning. Oracle Financials was doing the credit card transactions, orders, and all the rest of the sites DB work. The code had no impact on my dev, QA, and staging environments. We were hitting well over our minimum number of concurrent users. We deployed it to production and then the system got slower and slower, but never crashed. Again, production and staging were set up differently. Staging was a bare-metal server. Production was running on an ESXi server on a host that was split 4 ways. The multi-threaded code meant to detect performance degradations was slowing the whole system down when it tried to synchronize data across threads. I was pretty embarrassed by both these two issues. It went to show that production is its own special thing and that you really don't know if your server-side code is really going to work until it starts running there. 23:15 - Dead Button Way back when mainframes were king, a guy I worked with pushed a button in, that if released, would immediately take down the entire company. He stood there for 4 hours, holding the button in, until we could let it crash after business hours. We gave him a chair after 2 hours. 25:12 - No Deploys on Fridays I was a junior dev working on our company's website. They were HTML + nunjucks templates that were later being integrated with the backend using some Python witchcraft. There was also a metric ton of JS libraries added (like Babra for page transitions, threejs for a cool interactive animation on the landing page etc.). Didn't really get much of all this package.json stuff at that seniority level. So after running yarn or npm or whatever, and seeing some warnings about a couple packages being outdated, I decided to update some of them. It ran great locally, but I didn't build the prod version, as I didn't know there could be any differences. I was working on some minor feature (or maybe even some minor bug) and the PM decided there's no time for code review. So I pushed it to the repo, the backend guy did his integration, and launched it on prod. As it turned out, there were some breaking changes in one of the libraries I decided to update. It crashed the entire site. On Friday. At 4:30PM. And that, kids, is why you don't deploy on Fridays. 27:33 - Stupid Selfie Horror story for you Wes. I work for one of the biggest retailers in the UK and we were working on an app that would go on a ‘media wall' in their flagship store in London. Basically a giant 200-inch screen in the middle of the store that social content can go on. Turns out that I left my local Dev version connected to the production API when I uploaded a couple of stupid selfies of my big head in the office. Get a call the next day to ask why my face is on the medial wall. 28:37 - Soda I was a computer operator back in the late 1960's, operating a Honeywell mainframe. The consoles were huge, about the size of a dishwashing machine, with the console typewriter and printer inset in the middle, on top. I had a soft drink on the console, next to the typewriter mechanism. We were told never to bring a drink into the room but we all did it, especially on third shift. Long story short, someone called my name, I turned around and knocked the glass of soda into the console. Had to be completely replaced – machine was down for two days. My boss was not happy. 31:22 - Oof A bigger horror story. I had my own software company in the 90's and was in Singapore, customizing my software package for Johnson & Higgins Insurance Brokers – I had their Asian contract for my Insurance Broker/Accounting package. I spent a good 40 hours on Saturday and Sunday, making all the changes they asked for, getting ready for a demo on Monday morning. I finished up about 4am on Monday morning and was cleaning up my files. All this work was done on a Novell server. Print files had an extension of .prt and I had a ton of them in the main directory from all of the testing I had done. I was cleaning out old files, getting ready to back everything up and I thought I would delete all of the print files. I mistakenly keyed in erase *.prg, instead of erase *.prt (or whatever the delete command was – can't remember it now). Programming files have a .prg extension – I had deleted all of my updated files from the weekend. In desperation I called Novell in Utah, hoping they could help me recover the files, but no-go. The demo Monday morning was not fun. 33:24 - Young Dev I was a young dev right out of college. My first job was at a child support company where we had desktop apps that would handle case information more efficiently than using Excel. My first project was to write a POC that would later be implemented into a new, bigger app that consolidated all the “POCs” for various parts of the child support process. For some odd reason, I still don't know why to this day, my boss wanted me to write this “new” app on top of an old app with a bunch of legacy code. I never understood why but as a young dev fresh out of school, you tend to just do what you're told. In school, I mainly used PHP/HTML/CSS for learning how to work with a database; this job however used C#/.NET for their desktop apps so I was doing a lot of learning as I went. I remember finally learning how to connect to the database and run some SQL after fighting with this old pile of legacy code. In early versions, I chose to handle creates/updates for these records in the same function. My young, dumb self wrote a try catch statement that would attempt to create the record and if it failed, it would try to update the record. Before the first production release, I updated the flow to handle creates/updates in separate functions - but never removed the update in the catch block of the original function now used for creates only. Somehow I, or any PM/QA, never failed on a create and hit this catch block while testing. Fast-forward probably 9-12 months later, I got a ticket to investigate why every case's data looked the same in Production. I login to the app, search a few case numbers and sure enough, every case's data is the same. I began freaking out as I had no clue how this could've happened. I mean it had never happened in all the dev work, testing, and months of live Production use. After I investigated with a senior dev, we realized the try block had failed and the update query in the catch block ran for that record - we also realized that I left off the where clause in the related SQL query to specify which record needs updating - so ALL records got updated with this data. Thankfully, we kept regular back-ups and were able to restore the data to a recent timeframe without users losing a ton of work. We commented out that database update call and redeployed the code ASAP. Also the senior dev was cool about it and was like “hey, it happens to all of us at some point”. Let's just say I've learned a ton since then and definitely steer clear from writing code like that. You live and you learn I suppose. 38:40 - Where Wolf Here's my development tale of terror: One night I was burning the midnight oil trying to get caught up on a never-ending workload. At the time I was working for an online travel booking site. It was after 11, and the last thing I had to do for the night was to rename one of the hotels in our production database. So I wrote my query: UPDATE hotels SET name=‘Some Hotel Chain'; One problem, I FORGOT THE WHERE CLAUSE. Suddenly, over 5,000 hotels in our production database all had the same name. This was around 2003, so well before the time of point-in-time restores, and we were only backing up the database every week at that point. I was panicking. Fortunately, I had a dump of the production database that I had created only a couple of hours earlier sitting on my local hard drive. So thankfully, I was able to restore almost all of the hotel names, save for a couple that signed up after that data dump, and my boss was none the wiser. That's when I learned that working late hours is not worth it, because at some point you are so tired that you can no longer make good decisions. 41:19 - I Want Your Job When I first started out I worked for a consultancy and they trained us in sales meetings to help managers get promoted because we were coming in to make them “look good”. This was okay b/c obviously, we were coming in as a contractor; however, after being laid off due to 9/11 (yes, this was about 20 years ago), I was looking for a new job and during an interview when asked where I'd like to be in X years, I mentioned to the hiring manager that I wanted to eventually do what he was doing. Well, I guess he didn't take it that I wanted to make him get promoted to then take his spot. Safe to say I didn't get hired.

Coder Radio
437: Microsoft War Stories

Coder Radio

Play Episode Listen Later Oct 27, 2021 48:22


Chatting about the week's .NET news leads us into a blue-tinted tale of woe. When Microsoft taketh, they also giveth. But is it enough? Plus, which MacBooks we did or did not buy.