Join jLove conference for free or use discount PROGRAMMINGLOVE
OLI [00:00:23] Welcome to the Programing Love podcast, episode seven. I’m your host, Oli, and this is a High Fidelity podcast where we meet passionate people and discuss programing on this podcast. You’ll hear stories from individuals around the world on their journeys and the joys and pains they experience along the way so we can all learn and move forward together. Shameless promo from me. And today I also have my co-host, Anton.
[00:01:30] And we have a wonderful guest, Kelsey Hightower! Kelsey Hightower has worn every hat possible throughout his career in tech and dangerous leadership roles, focusing on making things happen and cheap in software. Kelsey is a strong, open-source advocate focused on building simple tools that make people smile. And I’m smiling right now. When he’s not slinging go cold, you can catch him given technical workshops covering everything from programming to system administration. Hello.
ANTON [00:02:10] Hey, I’m happy to be here.
OLI [00:02:12] Thank you so much for coming. So before you came here, before the episode, we were discussing that you’re a visionary, that you inspire and people in tech and also has your opinions on how and where the technology should or will go. So and I would like to set up the main topic for today’s episode is discussing the current developments and current trends in software. And we’ve got a few. Blog posts that we want to discuss with you, except one thing, you gave a lot of interviews, at least I found a few about cabernets and your career from the beginning and still dance. So I would rather not focus on that in this podcast because it’s already covered somewhere else, if that’s OK with me.
ANTON [00:03:22] That’s great. I’m looking forward to it.
OLI [00:03:24] OK, so Enten, you posted this technology over there, Trent.
KELSEY [00:03:33] Oh, yeah, like that’s that’s kind of a well known resource by Thoughtworks, where they built kind of a map of different technologies in a scale from adopt to hold or access or trial. And they are looking at different. Techniques, tools, languages, platforms, what would they adopt in their projects and what not, they’re what they would not suggest using for now or what would they suggest to assess or assess or adopt for others? I’m sure it’s not the latest issue. I think the latest latest issue of that radar has been published in December. So it’s not really recent anymore. So should we look at that first or we have another resource which was published yesterday about the languages.
OLI [00:04:43] It’s up to Kelsey. What do you want to look first at?
Kelsey [00:04:47] Anything is fair game. We can go in any direction, technologies, programing, languages. That’s pretty much my day job at this point.
Anton [00:04:56] Let’s look at the platforms there, are there. I will post a link in our chat so that we could look at the same page, I guess. Yeah. There it is. So it’s interesting that in this part of their report, they are not suggesting to look to adopt any platform, but they are just they have just mapped out the trial and assess categories mostly. And that’s a little bit strange. Or if you’re suggesting to adopt something, it’s it’s a major technology and doesn’t make sense to to put it on the map. I don’t know. But ways like I would put in to adopt any cloud platform there, right? So, like Google, Amazon, Asia. Any others, but for some reason, they are not there, but it’s interesting to look at the assess category. I think it’s the largest one in the report right now, like, for instance, Plumy. Have you heard about the looming.
Kelsey [00:06:12] Yeah, I mean, I’m looking over this list and things like plumy, which is, you know, if you’re familiar with TerraForm, know the whole infrastructure as code movement. You know, you had this idea that, you know, all these cloud providers have different ways of interacting with their APIs. You can pick a tool like TerraForm, which chooses HCL is its programing language of choice. And then the Plumy community kind of looks at all these declarative config and says something is missing, the power of a full programing language. And so we look at Pelamis, you know, there’s all of these libraries that try to give you these really clean ways of doing some similar tasks with way less code, but a full blown programing language, as most developers would expect. So if you kind of have this full stack engineer mindset, maybe you’re practicing dev ops where you share responsibility. I can see how some people look at me and say, hey, maybe this is the tool that we use instead of all of these maybe slightly different config languages. So I can see how, you know, maybe they’re starting to see people show up and say, hey, we want to try halloumi for our next project.
Anton [00:07:19] Well, it seems to me that there is like the crowd is separate, very much like the first part of the crowd would be like yaml oriented, but we can do everything in a declarative way and use the gun for that or any any other markup language. And then there is part of the community that says, hey, we don’t like all those drawbacks that this stickler declarative configuration brings and we want to have control over what we actually write. And we need better validation for for whatever we create. So, like, it sounds appealing to have compiler checks on your configuration, right?
Kelsey [00:08:06] Yeah, but I think in the case of this one, you know, like Cuban etiquette dictates that there’s a data model for everything it does. That’s just how that particular layer in the platform, other platforms like Cervalis platforms also are now delivering these declarative APIs. So now I think it comes down to what interface do you want? You want a command line tool? Do you want to just use Kerl and call the raw API? Do you want to use terraformed or do you want to use Plumy? Right. And let’s not forget about all the people that are still using Ansible, which is largely Python intermixed with some Yamal constructs. People are still using chef and puppet, which are largely either Ruby or their own custom. DSL, I just don’t think would ever be one. So I think what’s happening here is that more people’s preference of working. There are more tools that are showing up that aligns with that subset of people who say, hey, you know, I think one thing that is commonly shared. People do like the fact that there is a low level data model now. So if you want to go from plumy to terraformed or just writing Yamal by hand, that’s available to you. It wasn’t like that before. Right before you pick a tool, you’re stuck with that tool forever and you have to go rewrite all your code. And hopefully there’s a language module to interact with those underlying APIs. So I think we’re sliding into a world where treating infrastructure as data versus a bunch of APIs.
Anton [00:09:33] It’s like every problem in computer science can be solved by adding another layer of indirection, it sounds to me like that basically we have modeling that can generate it in whatever way we want.
Kelsey [00:09:46] I’m pretty sure someone’s going to show with a Haskell tool for people that want to do everything with pure functions. Right. There’s just no limit to it because there’s so many people working on these particular problems that they’re eventually going to solve it in a way that they think is best. And given the way open source works, they’re probably going to share with the world and it will get traction by a subset of our communities.
Anton [00:10:10] Yeah, but one interesting part there in this map in this quarter of this map, let’s say in the platform’s category, is the category where we have just not overload. Basically, I’m looking at what’s written here, and I guess it’s something against Noad. As nogs,
Kelsey [00:10:36] yeah, so I just clicked on it, so it’s basically saying, hey, look, there’s a tendency to use Noad indiscriminately for the wrong reasons, right? So, you know, maybe there’s an enterprise who says we went to some conference? You know, JavaScript is still arguably the most, you know, used programing language in the world. And so you go to a conference and you’re like, hey, you can use JavaScript on the front end and the back end. And I think a lot of enterprises just went crazy and says, oh, we can finally do it. We can add another language to our back and stack outside of maybe Java and now we can break in JavaScript. Now we’re cool, right? We’re doing Noguez. Everybody wants to work on Noguez. There’s like seven hundred thousand frameworks to choose from. We’re using one of them. And I think people just got a misguided I was actually reading the engineering or and I remember the team just really, really want to use nogs so bad. I was like, why do you want to use this for this back in project? I get JavaScript for a lot of frontin. It’s really great for that. Lots of knowledge, lots of framework. But the back for the micro services and restful APIs we were building, there was not a lot of value when we started to talk about resiliency. I like this thing would crash or how we would handle error recovery. And so it just it felt like it was more of a fad than a great engineering choice at the time. And I think a lot of enterprises have kind of made the same mistakes. And, hey, we want to write this in nogs. But why? Because we’re going to pick the language first before even thinking about the broader ecosystem for the problem we’re trying to solve. So I think that’s what they’re hitting us like. We need to hold on if using node by default for everything. We don’t need to use it for machine learning. Just because JavaScript is used in other places doesn’t mean we have to use it in all the places.
OLI [00:12:23] You know, I have something to say about this, so I’m coming from Schola World Times Carlip developer and there is psychology’s, which is allowing you to write Fronton in Schallert apparently. And that is. The justification for this is that you don’t have to hire a lot of different engineers, you have your spot what’s called developers, and they can do front end and peck. And so I think the same ideas here, enterprises, a lot of the times are excited about not just because they don’t have to hire people from hired different developers. They kind of found their way, found how they conduct interviews, how they like find resources for hiring people. And that’s one of the reasons, like you think, OK, I have the silver bullet and now I can invite a genius developer to my team and they can do both backend and front end.
Kelsey [00:13:42] I think that was the idea, right, and then you go and find out, hey, a lot of these platforms, the syntax is the least of your problems, right? Like if you want to go do iOS, the SDK is the library start to dominate. You know what? You’re going to get out of those. So, you know, maybe a company like we’re going to figure out how to rewrite all of the iOS libraries into JavaScript or JavaScript compatible. So we don’t have to learn those things. But we all know you get to a point where you have to break out into the native language to get something done and end up with a diminishing set of returns. If you try to shoo everything into one spot. So, yeah, it definitely makes sense why people would want to go that route. But I think a bit of pragmatism and honesty is required before we believe that there will be one framework for everything.
Anton [00:14:27] Or the thing is, even though it’s appealing to have the single language for both back end and front end and well, I’m guilty for that too. I’m part of Cocklin Development Team and we are aiming for back and codling for front and cutting for mobile and everything. So it’s appealing to have the same language. But you have a different domain, right? So the front end developer who works with JavaScript has a completely different domain and problems to work with than the backend developer. And where you have to think of databases, transactions, concurrency, whatever else you have, their resiliency. And on one front and you have this domain object model rendering and now downloading resources and so on, completely different domains where you can’t really just take one person and dropped into the other domain without proper training. Of course, the same tool will actually help a little bit so that you don’t have to now break up or learning a different language. Probably it depends, I think. But but it’s it’s an appealing thing to have the same language for different domains, I think still. But in this particular context that we had in in the rather on NOGs is like they are looking at it as an as at the wrong time, not as a language. Right. So you can actually write typescript instead of JavaScript. And I see a lot of companies are doing it like some some startups here in Estonia. I know that they are using nogs, but they’re they’re writing stuff in typescript and pretty happy about it.
Kelsey [00:16:24] Yeah, I think it will definitely work, I mean, if I have my choice, I’m probably picking something like Googling, just thinking about what that runtime particularly gives me and the standard libraries and the type of systems build with the goal. You know, this is probably why I would prefer for that particular set of tests. But yeah, I definitely get the appeal. But I’m just at this point, right. Tool for the job. I just it’s hard to shoehorn. I’ve seen people try to recreate libraries that don’t exist. And then instead of writing code, leveraging all of that cost savings from using the same language, they’re all maintaining a whole bunch of libraries to fill in all of the gaps because very few people are using that particular runtime or stack in that particular domain.
Anton [00:17:09] Right. So talking about the popularity of the language is we have another resource which was published just yesterday. So I think it was just a good intro to that topic. So we’ll read Monk. Well, you know, all kind of popularity indexes are there, like Tobey’s these DOONG. Some people like it. Some people hated. I actually hate it because it’s I think it’s not. I think it’s not a viable metric to just count the searches, but read Monks’ stats is something that I really like. They correlate the number of questions on Stack Overflow and and the number of repositories created at GitHub. So that one looks more like a true story for me. So they just published a new report yesterday and all a JavaScript is the number one there. And they say it’s it’s going to take a long time when it’s changes. So we we we have JavaScript here for good and for long. But the other languages, especially when you look at the bottom, like number 10, number 15. They are changing. There are some trends there, and it’s interesting that Ruby and Go are actually losing losing deposition’s. As they say, I’m not sure if it’s really true or not, but, well, they provide the evidence.
Kelsey [00:18:49] So I guess for me it’s like, what are you trying to win? I me like, yeah, I was contributing to a project written in one of these languages. That language will be No. One in that project because that’s how you would do it. So I kind of look at these like, cool. It’s kind of good to know if these projects are still seeing contributions. Is the maintainer ship pretty healthy? Is the governing body, is that healthy? What’s the roadmap look like? Is there a great feedback loop with their ecosystems, how the projects written in those languages thriving? Right. Are those projects still seeing adoption or people using them? I think when it comes to go, go is it’s one of those languages that gets boring really quick, which is why I like it. You know, you will complain about going to oh, it doesn’t have these twenty seven things. And the other language I was using that I don’t want to use anymore because it has too many things. So then you come over to go and you say, hey, I want something that looks familiar, but it’s one of those languages. Once you learn it, you find that you can actually do the things you want to do and the things it’s not good at. It tells you this. Isn’t that what we want to do? You should go pick a different language, a runtime. So I think go becomes that tool in the toolbox that just works for design purpose. And after that, it’s going to make a lot of noise about it. You just kind of know what you need to do. You may not ask as many questions on stack overflow going forward. You know, these days I have to hunt very little for how to do something and go. I can kind of just express my ideas. Of course, if I run to a new library, I don’t remember all the, you know, parameters to every function. But these days I don’t necessarily get too tripped up on how to implement things and go. So I’m one less person on stack overflow looking for content.
Anton [00:20:38] Well, I’m I’m right with you on this, because, like this this report definitely doesn’t show how healthy the projects and specific language are. It’s more like about popularity in the community by the two communities, that and GitHub and basically what what are the numbers there? Nothing, nothing really specific, but it’s interesting, still, like the newer languages, the newer are those who are like 10 years old already, like go and call them color. They are even 15 years old, oldie. But then we have BHB, which is still on the top. And I don’t I don’t know that many. OK, I’m going to bubble myself. I don’t have that many friends who program as friends, don’t let friends program and BHP. But still, if you look at this ranking there, BHP is in top.
OLI [00:21:41] There are a whole world of WordPress and plug ins and themes for that and everything is written on it. So that’s the thing. I guess what what I want to ask, since I don’t have a lot of go developers and recently, about a month ago, there was a blog post about generics in Girl. So what’s your opinion on that? It’s a little bit different from the main topic that we’re discussing. But still, I
Anton [00:22:15] oh, it’s it’s a many choice.
Kelsey [00:22:18] Yeah. I think the Go team was really focus on. Design the language for its purpose, and it turns out people want to use it to all kind of things like make databases, Web APIs, there’s even mobile development, there’s now way to generate code that can run on WASM runtime. So, of course, we started to attract lots of developers. And I think maybe even going back in the early days of go, people like you need generics. And they made one good argument like go internally has the ability to generate generic code. Right. For its internal types. But as a user of the language, I don’t have access to the same facilities that God does. And I think that was the most compelling argument to say, look, we have to do something here, but we didn’t want to make it a situation where people start abusing generics. I’ve seen this where you just go to some language like why are we using generics here? You just doing this because maybe you learned that this week and now you have generics all over the code. Have no I don’t understand why are we even doing this? Because we don’t even need it here. So the GO team was a very patient. We had a lot of great proposals. People like Robert Greeson more this guy like create the hotspot compiler for like he knows what he’s doing. You create the VA engine, right? He knows what he’s doing, but he also wants to avoid a bunch of issues in the past. So they were very patient with the proposal. So what do we have? Right. So when you look at the current proposal that is now accepted for most people, all go code will always look the same. If you’re writing code, that’s going to be generic code. We’re pushing the contract on the developer of the generic code to specify pretty much everything that can be accepted. We have a lot of safeguards so we can leverage the type system pretty well without throwing away some of the things that make us unique, like the way we think about objects, the way we think about embedding those objects. And so if you think about it, a module developer can add generics, but then the functio signature can look exactly the same. So we have the ability to infer that, hey, this is a generic thing. The compiler can tell you what you’re passing in is compatible. And what that means is that most people using generic code don’t have to even think about it, know about it, and it would just look like all other Gojko. This is a on the readability front, on the user’s front. I think this is a huge win. We don’t we’re not forced to write new syntax to invoke some method or something. This is great. You do have the option, though, if what you’re trying to do requires that little bit of syntactic sugar to help the compiler, you can do that, but you’re not forced to. So what they did was say, hey, the majority of code that will be written. We’ll look the same as existing coach, and I think that’s what took us so long to make sure we arrived at that because I think the generation before actually looked pretty good, but they couldn’t give that particular promise. So they put it on pause and kept at it. So where we’re at now, they’re going to have the ability to have some generic code that’s going to prevent you from writing too much boilerplate. I think our implementation is going to be closer to cogeneration than it is some other systems. But I think it’s a happy medium and it’s going to allow people to write just enough generic code without going crazy.
Anton [00:25:40] This is something that I like about simple solutions as well. If you look at Java Java’s generic right, they there are not so powerful as generics in other languages. But I was pretty happy programing with all generics in Java as well. They simplified some of my code, but I wouldn’t say that I could go into more advanced cases with generics. And if I look at Schola generics, for instance, this is like a computer science, like rocket science for me. I never I could never grasp that thing. All laughing a lot.
OLI [00:26:19] And you’re probably talking about her kind of tops and no bones and everything. Exactly. Another thing popped out in my mind, I’m sorry, I’m a little bit random, but I yesterday I was just reading this blog. I am not sure if I can find it right now about static types for Python. Just think about it,
Kelsey [00:26:50] I started, you know, when I when I after doing a lot of show programing, Python was one of the first like I guess, quote unquote, real programing languages I landed on. And there is a beauty to writing very simple outside of the indentation. I think that always tripped me up at some point, but it was pretty easy, right? You pick it up, you just assume a bunch of things and then you write 10 times more units to challenge those assumptions. Right, because of the lack of the type information. And so I think that’s cool. I think eventually people start to say, hey, I have no idea what this value is. Right. You have to then go and click five thousand times to say, oh, this is the dictionary or a list. And it still works, huh? And that to me is like we are writing code. It may feel like it’s a it’s a speed boost, but when you have to come back and read that no matter what anyone says, you now have to try to dig in and do some investigation to figure out what will happen here and the bad. I think the other drawback is sometimes you’ll pass a string and it will still work. And you’re like, well, OK, now do I put defensive programing here to say, hey, if this is not a list or dictionary, do not do this. And so you’re starting to ask, like, wait a minute, I thought you didn’t want the extra boilerplate. This is worse because now I get to read the body of this to figure out what will happen if I pass in the wrong thing. And so I think a lot of people are starting to realize is that there’s a balance. When I learn Java back in the day, I was like, this is ridiculous. I don’t know how you could write Java without an idea. It just is very ceremonious. Right. You have to put so many things on both sides of that equation that it’s just too much work. But in the world we have types, but it feels like Python most of the time. Our influence inside of that language is so nice that most people don’t think about types in the same way from other languages. So I think realizing that you can walk a delicate balance, you don’t have to trade off those aspects of dynamic programing and throw away all your types in the process.
OLI [00:29:01] What she said is, like the compiler can infer types. And this is still static. Typing But just was smart compiler, is that correct? What I’m saying.
Kelsey [00:29:19] Exactly, and then the runtime enforcement, right? So if I build time, it’s like you can’t you can’t do that. So now it’s like, OK, let me go and fix this code and make sure that the right things are being passed around. So that’s that front loaded communication. And also in our unit tests, most people, especially in go world, when you look at the code, it seems pretty simple, but we don’t have the right. All these kind of tests that say is if a dictionary gets passed in here, then do this kind of thing by we eliminate that kind of code. So I think there’s a nice balance of both worlds.
OLI [00:29:51] Which brings me to my lovely pond of functional programing. This is my place where I live, and the idea most of the time is that you make compiler do a lot of things for you so that in the wrong time you don’t have to care. Like if the code compiles, then it works. So how? Like is I don’t know how to answer this question, but is functional programing the future or not, in your opinion?
Kelsey [00:30:34] All I can do is talk from experience, I remember learning Haskell back in the day I was so happy I bought a Haskell book. I was like, this is so beautiful. I can take a value from one through infinity. And it would just say, I know what to do here. I won’t even evaluate this until you need it. I was like, this lazy stuff is amazing. There’s a bit of safety that comes from kind of some of the restrictions, some of the pattern matching a lot less. If it’s a lot less else, you try to avoid all these side effects and it’s beautiful until you need to open a file. Or you need to communicate on the network, then they say, oh, something, monads, something, something the universe is unpredictable. I was like, how do we go from this clean function that adds to numbers to the whole universe is unpredictable. And I think at some point the functional world has a reality is that very rarely are you going to work on code that doesn’t interact with the outside world. And so I think what you can say is that maybe a large part of your code base can be broken down into functions that are tight, easy to test, easy to reason about, and then you move all the things that interact with the outside world into its own layer. Right. So maybe the thing that takes a and a deep packet, you know, on Martial’s, it grabs the data out and then invokes one of these very same functions. But the way most developers work, most runtime is try to optimize for one or the other. Right. So it’s like, hey, I’m really good at this part, but I’m not really good at this particular part because I don’t give you the same ways to safeguard. So I don’t know. I think there’s going to be a mix where you can mix the two. I’ve done that in the Haskell world where you kind of write these pure functions and all they do is have a very simple interface. And then the thing on the outside is written in another language has better exception, handling better tools to reason about things. So I don’t know. I just think that that whole functional world, it’s great. I’m glad we’re aiming for that because things like MAP and this comprehensions are beautiful constructs that you find in other languages. So I think that that idea has helped us a lot to think about. Think about your input, think about side effects. And if you’re going to have them, put them somewhere and kind of express what they mean and what they do.
OLI [00:32:54] I’m glad to hear that.
Anton [00:33:00] Perfect, so we could probably change the topic a little bit and like make it a little bit more general, so there is a lot of trends and technologies appearing all the time and maybe even like bigger technology trends, like I remember sewing machine learning or artificial intelligence or anything like that. So and it’s kind of interesting question that was given to me recently. People are asking, how do you keep up with the trends and how do you learn about the new trends appearing? Because we are date today. We are hostages of social networks. We just we are in the bubble. We that we create for our for ourselves. Right. So we we know about the news, about the new programing language, whatever. We know about the news, about some some library or a framework, maybe a platform, but then the global trends. How do you follow the global trends? That’s interesting. And the how you get to know that there is something similar to machine learning appearing. So how do you cope with that?
Kelsey [00:34:13] I don’t you know, what I try
Anton [00:34:15] to do is you are on in your own bubble.
Kelsey [00:34:18] Well, I mean, the thing is, most of us in reality, we use the tools to solve the problems in front of us. Right. Like, I’m some fortunate for me. Only no one spoke in language. No English. That’s it. Now, I might try to go look up a few words if I’m going to go travel to another country, I say, hey, I got a new problem. I’m going to land in a particular country. And maybe English isn’t the primary language. What do I want to do? Do I get a little cheat sheet? Do I try to recognize at least a few words so that can help me once I get there? But if I don’t live there, I’m probably not going to commit to learning that language just to keep up with all the languages in the world. There’s just too many. So typically humans tend to gravitate towards tools that we need to actually use or use at some point. So when I look at all the technology trends, most of the fundamentals look the same. You got data that’s generated by a system, you can put all the data in a certain place and you can ask the data questions. Sometimes there are questions that are hard to answer because you don’t have enough data to look at trends like is this person going to buy red or blue shoes? Well, you don’t have enough data to make that guess. You probably need other data to predict that particular thing. So machine learning might be the right tool to start approximating things. So then it may be worth learning how to translate what’s in your mind into a model that the computer can use to train to make decisions as accurate as you are? That’s the fundamentals of machine learning. Do I have that kind of problem right now? No. Am I going to go spend time on a tutorial? No. And I’m OK with that. In the same is true of multiple programing languages like, hey, there’s Android and iOS. If I’m not building mobile apps, I am not going to keep up with the latest trends in mobile software development. I’m just not. But I might be curious, right? Like, for example, I’m using this propellor tool called Clubhouse Raices Audio only social media platform. And it turns out I want to use my nice fancy podcast microphone to talk on that platform. It doesn’t work. So did you go to the app? It just uses the default mic and audio setup that you use for making phone calls. So I’m like, what are they doing? So then I just go look at the iOS SDK and say, if I going to build an app and I want to give users the choice between using the default system microphone and the one that they have connected through USB C or something like that, how would you do it? And then you see the libraries that it’s possible. So as an engineer say, look, this is possible, maybe I’ll send an email to the team working on clubhouse to say, hey, I’m not an iOS developer, but it’s possible to use core audio to select the different audio interface. I would like to do that. So then maybe I keep up with this trend that most of these audio only apps default to the system microphone for some reason. Maybe it’s the Apple security thing, or maybe they just haven’t gotten around to it. But again, it’s only because I had a particular problem that encouraged me to go check out what’s going on in that particular space.
Anton [00:37:31] It totally makes sense, but I mean, what I was thinking about is like more. More into the innovation space, right? So when we talk about the problem, it’s not an innovation anymore, or we we probably can think of new ways of solving the same problem that was solved before. But for instance. I don’t know, innovation, how did how did VR appear? For instance, I think about
Kelsey [00:38:04] innovation, right? Some people say innovation, right? I’m going to innovate and do something that has never been done before. So you’re not going to go look at any tools because you don’t even understand the problem yet, so you’re going to spend most of your time trying to get that problem in front of you. So if you want to build VR, you’re going to ask yourself. I know it’s hard to do this, we know what three days is, we know how that works, but we want is to interact with the world like we interact now. And someone will say, oh, that’s a that’s a tough problem. What you’re going to need is this is the state of the art technologies. Well, I want people to be able to wear it on their head. It’s like, well, now you’ve got to learn about how humans and their eyes operate together with their mind. Here’s some research around that. Once you get all the research, you might actually find that there’s nothing that you can download to just play with. So that approach of like downloading a bunch of stuff and playing with like that’s not innovation. That’s called that’s like shopping. But if you’re going to bake a cake, you’re not innovating on bakery. You’re not. These cakes have already been baked. If you find a recipe, are you walking down the grocery aisle and it’s like, hey, here’s an ingredient that goes into cakes that’s not innovating. That’s like getting the ingredient, put it in the cake and tasting it to say, oh, this cake actually tastes good. Now you can mix other things that maybe other people haven’t tried before. Like you want to remix something like what if I put Pepper in a cake? What would that taste like, maybe I’ll try it. I think that’s really what it comes down to. So maybe you do have a creative moment where you say, I think this is where engineers get into trouble. We’re bored. You say, hey, this thing is working great. Hmm, I bet it can be faster. Do we need to be faster? No, but I bet I can make it faster. So I’m going to read write the compiler so that we can inline some of these calls. Now, look, if there are real people, you know, having this problem, maybe that’s where you spend your time. But a lot of times we catch ourselves just doing what I don’t like no gas anymore. I like I like Haskell, so we’re going to rewrite everything to have something to say, but why is that? Because I want everything to be pure. I want to avoid side effects. You like what are you talking about? You’re going to eventually have some. I know it’s going to be pure. So I think a lot of times we’re convincing ourselves we need to stay up to date on all of these things. Just say, look, we like technology, right? If you like cars, you may want to go test drive cars, even though you don’t need them, even though you may not even be able to buy them. Right. You might just say I like cars. So I think what technology can do is say we like technology, we like new frameworks, even the ones we don’t need. We just want to see what the are the possible is. Maybe we don’t have to use it in production. We just want to stay up to date. I think that is totally fine. But we have to separate it from it’s our professional responsibility to know about all of these things versus our curiosity to want to know about these things.
Anton [00:41:05] Well, while you were speaking, I was thinking about science fiction, a lot of things that we haven’t seen in real life actually appeared somewhere in books or scientific or fantasy movies. Right. I’m just recalling Johnny Mnemonic when he was putting on this VCR thing on his helmet, on his head and doing something with special joysticks or whatever they were the gloves. I don’t remember at that time. It was kind of a common technology or anything like that. But, hey, in 40 years now, we do have all that in the grocery stores.
Kelsey [00:41:52] Yeah, I mean, I think I think what you’re kind of describing, though, is people typically will imagine the problem or create a problem that they would like to see solved. And to me, that exercise to me in some cases can be more important than just looking at all the tools available because who creates who who’s the one that takes time to step away from the keyboard to see what the problems are in the world? What could be, even if I don’t even if I can’t find a tool that could do it yet? What should be possible, and this is where I think having room like science fiction that you alluded to a place and space to imagine what could be possible, and then maybe you’re right, over time, people would say we could create that. There’s a way to do that. I don’t have all the answers in this decade. Maybe it will take two more to get to. But, yeah, we still need to validate some of this. I think there’s been a lot of problems humans have cooked up that turned out maybe society would have been better without them. Even if they’re convenient, they’re not necessarily always the best for our human being.
Anton [00:42:58] Can you give an example
Kelsey [00:43:00] if you think about a cell phone, for example? There are a lot of people addicted to cell phone, right? We always talk about the pros of a mobile device, right? You have maps, you have a calculator. You can transfer money to people. But what about the side effect of saying people spending 10 plus hours scrolling, scrolling, scrolling? And if you’ve ever seen any of the sci fi movie since you mentioned them, like Wolly, where society gets to a point where all we do is we sit down and we stare at a screen and there is no more point to live. Everything can just be virtualize. Now, some people may say, that’d be great, I can be an avatar and live in this digital world and buy digital clothes and just sit there with the convenience of VR and never have to move and eat food through a straw. That’s not that doesn’t sound awesome to me. Like the things that make us human is that things are hard. You can’t jump higher than you can jump. You can’t jump off a tree without getting hurt like there’s there’s limitations to it. But those limitations are what to me defines life. And so if you try to remove them all and put us all in front of a screen. Who are you at that point? Right, so to me, I think there’s limitations to a lot of things, right? Some people would argue certain weapons. What benefit do they have to society other than to create war? Some people say, well, depending on what side of the war you’re on, it’s a very great tool. But kind of the consensus is there’s really no winners when we think about how humans are connected. So there’s lots of technology that I think people would look at and say, did we really, really need that? We rethink that if we knew what the side effect was, right? That’s the decisions we have to make like software developers do. I really want to import this, Liberi? Their security threat after this. Should I even be using? Should I read the code that’s underneath these covers? These are things that I think from a technology point standpoint, ethics and responsibility are part of technology, technology, how we serialize our cultures and build tools for ourselves. But not all of those things are going to be in the best interest for human beings.
Anton [00:45:17] You just funny stuff you mentioned, like scrolling being a problem, like if you scroll with the finger and I was thinking like, how can we solve this problem so that you don’t have to use the finger? But that just
OLI [00:45:33] was functionality for LG phones a while ago where you could look at it. Actually, somehow I things like magic, it curls without use, like scroll and you just look at the bottom of the page.
Kelsey [00:45:50] So there’s somebody solving this problem or improving the UX there. Right. So it’s not really a problem of using your finger or having sophisticated.
Anton [00:45:58] Sure, sure.
Kelsey [00:45:59] I think when you have a person scrolling through other people living, oh, look at these people outside playing basketball. Oh, look at this person planting flowers all day. You’re watching everyone else live. And you can just go outside and look at the flowers. You can go outside and listen to the wind blow, or you can go on your computer and watch other people listen to the wind blow. That that that, to me is just like this constant struggle society has, that there is a life, you have limited time, and so this act of game of endless content versus creating content of your own right. There’s nothing wrong with just going outside, looking at the world and just taking it in. We don’t necessarily have to put it on Snapchat or some other social media. You can just enjoy the world for what it is. So I just think that. Life can’t just be a thing when we figure out how to sit in front of a screen forever.
Anton [00:46:59] That’s true. Only do you have any other, um,
OLI [00:47:04] you know, I was just thinking that while in current teen and all this pandemic stuff, you kind of. Have to look a lot at your screen
Kelsey [00:47:18] or do you I mean, I learned how to cook a lot more dishes during quarantine.
OLI [00:47:23] Yeah, I just mean, I don’t have to I mean, I don’t go to the office now and I have to spend a lot of time at meetings and I don’t go to conferences in those terms.
Kelsey [00:47:37] Oh, yeah. Yeah. I think the having a screen to fill in the gaps of things we would have had to do anyway. These are extreme circumstances. So I’m not saying the fact that we’re using those tools are necessarily a bad thing. Right. Someone asked me what would I do if I retire now? 10 years ago, I was struggling for answer. Someone said if you had the ultimate freedom to do whatever you want, what would you do? And when you draw a blank, the next thing I ask myself, why don’t I have an answer for this? And my kind of stuck in this loop. Where if I was completely free, unconcerned with those things, that I couldn’t do anything else with my time. How do I get to a point where I wouldn’t know what to do with my own time and freedom, right? So that’s where I look at these things. So, yes, if I got to take a meeting and I can’t do it in person, I can use my phone to hear the other person’s voice, where I can jump on a video call like this to interact with those people and enjoy like body language and being able to see their face. Totally agreed. But at some point we all get fatigued. Like at some point you say, that’s enough. I can’t do this for eight hours a day.
OLI [00:48:49] Yeah, our previous episode with Scott Hansen, where we’re discussing techniques how to get less fatigue from zoo calls, and he was saying that he has a good display like TV and he turns on speakers and has a little microphone and he feels almost Quilt’s here, like in person because he seems like a real size. Something to close real says people, and he can walk different things during his meetings, so that helps him. What do you do to help?
Kelsey [00:49:39] Well, I’ll use my phone a bit more like so, you know, I don’t wanna set up the whole screen and everything, but I’ll just take my phone, put my headphones in and just go for a walk. All right, I can go breathe, I can walk around, I can move and I can hear the other person, right. And so that has been nice, right? So I can combine a little bit of exercise getting out of the four walls. And now it kind of feels like I’m walking with the person. Right, as we’re communicating about a thing. So that’s been a nice way to kind of break things up and that all of my meetings, of course, but there are some meetings, especially if I know the person already. I think video is good. I mean, you’re kind of getting to know someone or meeting them for the first time. But if you really know someone, then sometimes you can just do audio like when you call your friends. Right. And you just you probably know what they’re looking like when they say something. You understand the inflections in their voice, et cetera. So that’s one of the tricks that I like to do or cleaning up. I’ll talk to people while I’m doing the dishes or something like that.
OLI [00:50:39] No, I don’t know, I don’t really do anything specific, except probably sometimes I have my dog running around me and that helps me a lot anyway, so. I think we can wrap up here because we’re already talking a lot of time, and thank you so much for coming.
Kelsey [00:51:04] Awesome, thanks for having me.
OLI [00:51:11] goodbye. Bye.
Our TOPPODCAST Picks 
Stay Connected
