Fixate on Code #19

Fixate on code episode 19 Hole right, LarryBoy secure? And you are listening to Fixate on code, the weekly Bite size podcast where I talk to the best steps. About their favorite strategies for writing great code. Now, let's chat with today's featured guest, David Khourshid. David, thanks for joining me today. Thank you for having me. David works on Microsoft's visual Studio live share, a service that enables developers from anywhere in the world to collaboratively code, debug, and more from the comfort of their own visual Studio or visual Studio code editors. With his awesome work on CSS animations, and, more recently, his work on XState, a library that makes managing states and user interfaces easier. David is an innovative force in the CSS and JavaScript world. David, can you fill in some of the gaps in that intro and tell me a little bit about what you get up to when you're not writing code? Well, that intro was pretty spot-on. I'm a mostly a front-end developer, JavaScript and I'm also a pianist.

I. I graduated the University of Central Florida as a Peon performance major, and so I enjoy playing piano. I also enjoy traveling and spending time with my dogs. So what are you most passionate about as a developer? Well, to me, there's two things and that they're really doing the, you know, same thing. It's user experience and developer efficiency, and I say they're the same thing because developers are users too. And so I. I'm always thinking about how we could reduce the cognitive load on user when they're using applications via animations or smart user interfaces or thoughtful design. And also having developers work as little as possible to achieve those goals, so that, you know, they don't have to be coding 80 hours a week. Hmm, well, right now you're working at Microsoft now, you've done awesome stuff. Encode, Pin, your CSS animations are unrivaled in what's going on there.

And you've also worked on XState now completely changing the way that people are starting to think about states. What are the steps that got you to where you are today? Well, it's funny because I first want to be a musician. We have this intro to music tech class, though, and our final project in that class was to make a marketing website for yourself. And there was this program called iWeb, that you used to drag and drop things and make your own website, but I was lazy. I didn't want to go all the way to the University and use that program to make my website. So I decided to research and figure out how to do it myself in using CSS, JavaScript, HTML. I did it and my professor told me you should be doing this as a career. So, so, I started working at the college and I was initially working on WordPress, PHP, and a little bit of JavaScript.

And that's when I started just experimenting with the front-end world. And I eventually found code Pen where I started to make all these fun experiments.

Play from 0:00

And challenged myself by doing things only in CSS and HTML and trying to see how far I could get without JavaScript. And so, by intentionally limiting yourself, it really brings out a lot of creative potential. And so from that, I guess a few mic opens got a lot of attention. And I've gotten job offers from places in San Francisco. And ultimately, I worked really hard to make a name for myself. And I guess Microsoft noticed me, and so here I am. Alright, David, can you take me to the worst experience you've ever had on a project? Well, there was one time my first big job I was, I don't wanna say I was forced by. Was coerced to stay up until 5:30 in the morning at work. Working on a project that ultimately went nowhere, and it was just like, you know, that project from hell. And my manager was there too. Til 5:30 in the morning, I took a half hour nap on the couch.

It's terrible. And nothing came of, nothing came with that project right now. It was ultimately scrapped, not because I quality, but just because of higher level business decisions. That said, like, Oh, we actually don't need this. In the deadline that we gave you, you know, it doesn't matter since this project is scrapped anyway. What was what was the biggest takeaway that you got from having gone through that? Since? That was my first big job. Like outside working at the college, I learned that it's extremely important as a developer to be an active participant in the higher-level decision-making processes. So that you're not just beholden to whatever your manager says you have to do, or whatever be a you're a project manager, anyone higher up, you know, tells you what to do. But instead, you should be an active voice in making those decisions. I think also what's unfortunate is we often push ourselves so hard as developers trying to get work out.

And after only a few hours of Dev, you can only do so much. And I think people on all levels forget that, especially in a managerial position where they just need to get stuff done. And you're pushing people for that degree. I mean, working to help us. 5:00 in the morning. You probably would have been more productive in two hours off to six hours of sleep than having worked. I don't know, you work through the night, basically. Yeah, I mean, I am a bit of a night out, I love working at night, but I mean, that was a bit excessive. And yes, you could be more efficient after sleeping, but you could be even more efficient by just being active in those higher-level decisions. Where you could say, Hey, maybe we don't need to do this at all. And doing no work is the most efficient work now, david, in terms of getting quality work done on a daily basis, which method or tool do you use that you'd hate to be without?

Play from 3:00

Well, currently, I'm always on VS code, I used to be on Sublime. But VS code has so many extensions and an extensive marketplace for all these extensions. Where basically anything you could think of that you would need to help you in your day-to-day coding. It's it's available there. So I use VS code all the time in, you know, since I'm working on VS code extensions for visual studio. Live shared like you really get to know the ins and outs and what VS code is capable of, also code. Then I go on Co Pen every day, either to find inspiration or look at coding techniques, or see what other people are doing. Or as a scratch pad for my own code. I also cannot live without the developer documentation. Because, despite its name, it's actually a collaboration between Mozilla, Google and Microsoft's working on improving these docs and making them as comprehensive as possible. But the absolute tool that I cannot go without are just pencil and paper.

Those are the most important tools to me as a developer, because, you know, it's great to just get your thoughts on something tangible. How? How is visual Studio live? Shay? How is that changing? How developers are working together? Is it a replacement for team X? How does it compare to something like team X? So visual Studio live share. First of all, one of the major goals is that it's meant to be a collaborative environment from the comfort of your own editor. Currently, we support visual Studio and visual Studio code, which a lot of people are using already. And we're hoping in the future to expand that and make it available to more, more editors and more platforms as well. Also, it's not just it's definitely not screen sharing, so you're not seeing the other person screen, which, you know, can also be a huge advantage. It's more you're sharing files between people, you're sharing context in which you know you would be coding in one file, or debugging, you know, in another file, or even running a live app.

And the person you're connected to can also see what you're doing and have that code working on their machine as well, it's crazy. And so it's all developer experience, so it's not just text sharing, it's not like just Google docs for coding. It's it's a lot more than that, and there's a lot of really cool features planned for this. So now we're in your daily work, do you still get frustrated and where do you feel there's room for things to be done in a more effective way? Well, they say that hell is other people's code. Yeah, I'd like to. I like to expand that quote and say, hell is other people's code, or code that you yourself wrote a week ago. The reason gets so complex is because we have all this complex application logic, or you could think of it as business logic. What? The logical flow of the code only exists in the mind of the developer that created it in, so it's not immediately clear to anyone else by reading the code what the codes purpose is.

All they see is like, Okay, yeah, before the what's this for loop for what, what do? If statements mean, and this is traditionally known as spaghetti code, unless it's written by a senior developer, than it's lasagna code. Still, the Italian flavor. And so I. I look at these problems and I'm like, these can be solved by, well, by. First of all, just simple, modular ization out of the basic level, just organizing your code, but also just thinking about ways to offset whatever's going on in your mind and putting it in the computer so that the computer can understand it as well and so that your intentions are right there on the computer in the declarative way, so that neither of the developer nor the computer has to guess what's going on in your head when you're making this logic.

And I suppose a lot of this comes from the move away from imperative code and towards declarative code. I mean, I know, on my side, having moved quite a fair way from imperative code. When I go back to code that I've written, I can't read it. A week later, I'm not sure, about two weeks later, but there definitely is that major difference in declarative code. But I mean, that's just the beginning, you're still, you're still working with mountains of different files, other people's code, trying to get other people to understand what you've written as well as what you're writing. So, I suppose, is a whole number of levels there that you have to try address, right? Yeah, and what you said about the clear code is absolutely correct, where it's definitely a step in the right direction, and we've already proven it. A lot of our imperative code is basically us thinking that were smarter than the computer. It's like computer, you don't know how to do this, so I'll help you figure it out.

Whereas declarative code is like, Hey, I trust you, you know how to do this. Let me just give you the most minimal information that you need. And that's extremely scalable, flexible, composable, all that stuff, especially mitzvot functional programming, because declarative and funko hand-in-hand. One of the examples I'd love to give is people love to whine about CSS, right? Everything's broken, whatever, but imagine that there was no CSS. Imagine that we had to create absolutely everything on the browser or on our web pages with just I'll know. The canvas library, which is completely imperative. Then, if you handed it off to another developer, they would have no idea where to start. If they needed to move something, one pixel to the lab to recall or something, it would be a mess. At least with CSS, it's like there's a declarative way where it's like, okay, if I want to change the color, I literally just change the color. Property. Yeah, Ancing with HTML, so thank God for its team.

CSS how do you feel about the impact of Jeaious in CSS and people's perception of CSS? Do you think it's helping people adopt CSS? Or do you think perhaps it's masking? Problems that people perceive in CSS that maybe can resolve through a deeper understanding? What are your opinions on RJS in CSS is changing the way that people think about CSS? So I remember about, I think it was about a year ago that there was just this whole big debate on CSS and J/S, whether you should be using JavaScript for styling, your CSS for styling. And honestly, in my perception, I've seen it go from one extreme to the other, and then just meet comfortably in the middle. Because people realize that. Trying to try to shoehorn CSS into a JavaScript context is a leaky abstraction, and it's really unwieldy and, you know, just weird to do. And so there are libraries that actually provide a good balance for that. Of course, your CSS, some modules where it's like just sprite CSS and then just included.

And everything's modular and more component sized. And there's also styled components, which I personally love. Because it's CSS and JavaScript, but it doesn't feel like CSS and JavaScript. The main takeaway from all this, though, is that when we component eyes and modular eyes CSS in a more robust way than just random class names or selectors everywhere, then we get much more predictable styling. And so that's something that you could carry on, whether you're using just CSS or a CSS and JavaScript thing. Yeah, so it's really useful now in terms of new projects, libraries or frameworks. What are you most excited about at the moment? Well, one of the thing I being excited about, but I'm super excited about because it's slowly coming to version 6, is RxJS and so arts.

Play from 6:00

Jeaious has been around for a while. However, I don't think that arts J/s has seen the, you know, the explosion of popularity that, like save Reacts or Redux has found. But the thing is, RxJS is extremely useful, and it definitely fits the functional and reactive and declarative paradigms. And it allows for treating time as a first-class citizen where you know most other libraries, just forget to do. You have to deal with promises and all of that. And a related project that I actually saw yesterday is Luna, which is a language, and if you go to Luna - Lang Org or Calm or something like that, then you'll see. It's a very visual, functional programming language, it's really cool because you could manipulate things in real-time and see how they're affected. It's a flow based programming language, and honestly, I think that's the future visually Augmented flow based functional programming languages.

Also, I'm working on XState, as you mentioned, and I'm excited behind the growing community involvement in it and in deciding, like, how do you do certain things with it? How should we approach this? How should we approach that? So I'm excited for using XState and more things and making like visualizations of state machines and things like that. Now, with all of the new languages and libraries and specs and all the stuff that's coming out all the time. How do you decide on what to learn, and how do you make time to learn? It's funny because whenever a new library or framework or whatever comes out, I ignore it. I mean, maybe I'll read the readme. I'm not going to immediately try to learn it and play around with it, instead, I'm going to try to see what fundamental aspects does this library or framework touch upon? So, for example, Redux, you know, it sounded shiny and new, and honestly, when Redux first came out.

I wasn't really that interested in learning it until I absolutely had to. But it was more the idea of, you know, the pub/sub pattern, you know, dispatching, subscribing, all of that, mmm, that really interested me, and that's what I learned. So, basically, learn fundamentals, not frameworks, because all of these frameworks and libraries are built on fundamentals. And if they're not, then you shouldn't be learning them anyway. Mm-hmm, especially with all transients. Everything we work with is it's just a new library all the time. And and there are those fundamentals that you can learn and hopefully take over to whatever new library or framework, or even language when that comes along. Exactly right now, which specific aspects about programming has dramatically changed the way that you think about and write code? David so, I think it's no surprise, but basically, having your programming be declarative, functional, and reactive.

Mmm, these all fit into the general idea of letting your computer think for you instead of you having to do all the thinking. And you just Apple your thinking into code. You, you trust the computer to do it all for you, and that's where declare functionally reactive programming makes the most sense. That even goes further into tooling, with letting the computer do its job. I mean, if we take a look at something like pretty Egeus, you're eliminating something which you shouldn't be doing. Why are you formatting your code? shouldn't you just be writing your code? Honestly? With with prettier, I type, I type worse, or like, I could just be as sloppy as possible and just, you know, command us, and it just formats it. But how much work other languages now that you don't have prettier in OMA? Weird, it's. It's a nightmare. Doing any reformatting in anything else now feels like I don't know. It feels like I'm hitting my head against the wall.

Pretty is, I think, could it? Pretty annoyed me? I do. I write terrible jeaious. Now my JS looks terrible, and it makes it look great for me. Yep, alright. And with that, we've come to the end of our first segments. David, I'm about to throw some quickfire questions your way, let's do this. What is the best advice about programming that you have ever received? I think I heard, if something can be automated, just automated, don't, don't think about just let the computer do it. Which personal habits do you attribute to writing better code? Literally writing pencil and paper? If you could get your thoughts down, draw diagrams, that's the best way to go. If you could recommend one book on programming, what would it be and why? It's sort of an expensive book right now, hopefully you could find at your library. But it's constructing the user interface with statecharts by Ian Horik. Why is that? It's? It's a really important book on describing how the idea of state machines and statecharts are influential.

And really important. To designing user interfaces that are bug-free, maintainable, and do exactly what the user wants, who in the front-end world is doing work that's really inspiring? DAVID Oh, there's, there's a lot of people. For four years it's been Sara Dresner, Val head, Rachael, Neighbors. You know, Kravitz, Mary Lou and the Tutor, which are all very recognizable names in the world of CSS and animation, and especially Mary Lou, who runs Timpanist Ed /Co Drops. Ever since I started programming, really, she's been extremely influential on just inspiration for how I create user interfaces and all that her. Her work is utterly amazing. And also, breath. Viktor, who runs where he trained, taught nets. And he made a ton of really awesome presentations on the future of user interfaces and what programming languages and user interfaces could look like and should look like in the future. Hmmm, nog, David, imagine you wake up and you have no recollection of ever writing code.

With your knowledge of tools, books and courses available today, how would you go about learning to program from scratch? Well, I'm sort of cheap, so I. The first thing I would do is just go straight to the documentation because the documentation is freaky, and I would start, you know, reading up from there, read the entire documentation. Try to learn as much as I can from vets to get started on learning whatever language I decide to learn. And immediately from there, I'm not gonna touch any other tutorial or book just yet because I'm going to think, Okay, what can I make? Mmm, how can I apply this knowledge? Because I learn best from example and I learn best from doing things.

Play from 14:00

So I'll try to make a sample application. And if they're something that I don't know how to do, I'm going to google it, maybe find a tutorial and then work from there. And David, let's wrap up with your top tip on how to work smart, and then the best way to connect with you. Okay, so my top tip on working smart is well. It really feeds into the question of. What is considered like a good developer, it's not to me, it's not a developer that works 80 hours a week or writes thousands and thousands of lines of code. But it's the developer that can successfully manage his or her work and find the free time to do things that truly matter, like spending time with family and friends. Because it means that you're doing your work efficiently, and you're finding the best and the most efficient ways to get things done. And to not spend hours and hours coding, and rather just having the computer do it all for you. And, you know, living life.

So everyone out there you've been hanging with David Khourshid and Larry Buta? Head over to fix a Thai tea, where you'll find links and timestamps for everything we've been chatting about today. And, of course, head over to XState on GitHub and see how finite state machines can simplify your UIs. David, I want to thank you for sharing your journey with Fixate on code, keep pushing the limits and keep a shrink gray code. Thank you for having me, it's been fun.

Play from 21:00