Hi everyone, My name is Patrick Aku, and if you're interested in how software engineering is evolving, this episode is for you. Joining me today is Boris Lav Nikolov, previously principal engineer over at Booking and now hands on CTO over at Recce. He solved many complex large scale computing problems and I love picking his brain. What makes a software engineer great nowadays, especially how this role is evolving. So enjoy.
I've been in teams where people, certain people of the team like executing, like, for example, delivering value to customers and other ones like solving technical problems. And then all of a sudden those people address more technical problems that we have because they're like solving it. And there's like this disconnect because from a business side, they want functional requirements or at least functionality for users that drive value.
And then the people that love solving technical problems want to solve those technical problems, but not every technical problems needs to be solved. It really depends on kind of this business context. And I feel like not everyone has the scale of, let's say, a booking organization. So then there's this itch probably that never gets scratched. Yeah, yeah. And that's a hard one.
Yeah, I, I think one thing you can obviously do is just go and see what people do. Like just go to conferences and just get out there and just see and meet people. Another one is to just work with constraints. If you another way to fake it basically is just well try to make a good program on this account of 6564 or like just Z80 or like some something with like few kilobytes of RAM and super slow disk. And this also makes it
interesting constraints. Basically if you say I only have like try to do something, I can only do that in 10 lines of code. So this has to be 10 lines of code. That's why it was sometimes just when I have to do something or or just look at each word, each, each keyword that you write. It's like, how can I write this in the what is the cleanest for me? I don't think there's like a generic clean code thing.
But for you as a individual, what is the, what are we going to be like just proud of if you just write this like 10 lines and then you can just kind of like get away from the whole thing. The octopus that is like happening and have because in enterprise, everything is connected to everything. It's just a huge, nobody knows if a code is used. You know, let's say, let's say designers have this problem with CSS and you can't delete anything because you don't know if it's used.
And so how you just keep like piling, piling, piling, piling, right? But you can just even in that situation where it's just a pile of like disappointment, you still can find like islands that you're still can express yourself. I see what you mean. So just don't, don't be like, oh, it's just, oh, shit. And I have to do it. And I just have to.
You can still like try to find these moments of the creativity and nobody's going to value it because it's not going to bring more money, but but it's going to bring value to you. Yeah. So I think that's people should do that more. I think I. Like that a lot like it's experimenting with things that kind of you do day in and day out that brings you joy. Yeah. Yeah, right. It's nothing bad is going to happen. Maybe somebody on the code review is not going to
understand it exactly. And then you'll be like that's fine, it's OK. Yeah, it's OK. Yeah, yeah. I mean, it's hard because I've seen people who really get attached to the code they write, right? And specifically, when you figure out something that you really like and that it works, when it comes to code review and people critique it, that's where a lot of discussions happen. I think they have to realise it's not, it's not personal. It's not, it never is.
It's not, it's not personal. Yeah. Look, I'm very unfortunate that a lot of the code that everything is still running. I just wish it wasn't. I think really. Yeah, I think I. Why is that not good call. But the I'm the happiest when I delete my code and just so happy somebody else comes in. It's like, I found another way to solve this. I'm like, that's the I can learn a new way to solve this.
First of all. And always when you write something, you have to give it like, I mean, the desired first we have to make it deletable is the most important thing for basically technical that if you can make code deletable easily without like as few tentacles as possible, it's easier for the company to grow. And so that's why I like, I'm really happy when my code is deleted also because then you don't have to be on code for it. But the once code is written,
it's done. You're, if you've looked at a code that you've written like six months ago. And if you don't find that like disappointing, then you just haven't grown. So you should be like really happy when somebody your code is outgrown so that you by you or by somebody else so that you can just look. Interesting, I've never heard this approach of writing code that would be easy to delete let's say.
But I do like like I've. The most experience I have is with Go as a programming language and there the language is set up to be simplistic and also with the words, the interfaces, separation of concerns. I think I would be able to delete things easily to be honest. Go is particularly, I think Go is, I mean, it's the language is quite, I don't know, boring. I'd say I love it. I I mainly, well, I also called
male lingo at the moment. It's just it's you don't think you just code gets written if, if, if, but you don't. There's no cognitive load when you write go when you write like, I don't know anything. Actually. If you write list it's like OK, what? What's going on here? There is a thing called the fork. People say design at the keyboard. So which means that as you're typing the code you're like making it. And that's what you have in single just design at the
keyboard. You don't actually think about, you can just write it out. While in a lot of other languages you have to like if you write a fork program, you can't, it's impossible for you to write like that. You have to make it on pen and paper and just see what am I actually going to do with components and what I'm going to write. At least be similar as well. So anything that's designed the keyboard, just there's no cognitive or that's the point of goal. Yeah. And just write the thing.
And it's like simple because if it's simple to write, simple to read. Exactly. So I think it's OK, just not very expressive, but it's a really productive language. You think it's good for like longevity? Because that's usually the argument that I use. If it is simple to write, it's simple to read. It can be maintained for a longer time. I don't. I don't you know, when the first version of Kubernetes, there are a bunch of Java people I think wrote it.
So if you look at the code, you can write Go in a kind of like a Java way. Yeah, you can write Go in kind of like a sea way, but you can't go all like it's quite a centrist a little bit. So for longevity and what helps a lot with you actually for longevity is tooling because of the way you can pass it and the way exceptions do not bubble. First of all, panics are not idiomatic.
Yeah. So I should, I think that's what helps for longevity is because you at a tool can reason through the the tree and be able to find for example that code, unused code, etcetera, etcetera. That is much, much harder when it for example, let's say in Java, let's say use like Lombok or something that that just injects it's an invisible code and then you don't actually know what's happening and nobody knows what's happening. That's just not the case in Go.
So I think that's actually what helps with longevity. It's not the syntax, it's just the well, particularly the the no exception, nothing. It's also that's why I think Go is a great language for like language models to write and read because they don't Transformers, they are shallow. So I don't think they can Oh, that's that's good to say They they they they are shallow as in shallow circuit. They can approximate shallow circuits and they can't recurse.
But in so therefore if you have exceptions like something is like bubble up all the way down from the start, they can't think about it properly at the moment, right. That's where we are now. So in go, that's not the case. So they can it's just very linear. You know how how errors propagate. Yeah. So if you. Have to handle them. Yes, yeah, yeah. It's just not idiomatic to panic. No, even of course you can people try to cover.
There are some you can see that some people like try to say, oh, I just want to try an exception. I catch, I catch all this. So I'm just going to fairly cover here and but that doesn't pass the code. It's not a No, it's not. Just yeah, even interface direction to the amount you can go if you people, I mean they are of course, but they're more like readers and etcetera, but not all. Let me just add the like an abstraction between those two. Let me. See.
No, not without a point. Yeah, exactly, which is not the case in like Java, for example. Yeah. So that's, and I think that's what makes it maintainable because you don't have extra layers between what's happening and what's using the thing that this bridge. So therefore it's really easy for you to read and and go down and up if you. I think it's really easy to onboard in a Go project because of that. Yeah, because just you just read it.
You don't have to guess, you don't have second guess what is actually going to happen when I when this function is called. Yeah, I can just read to it, which is not the case in most other languages. Exactly when it comes to like languages, I see them as tools. For me, the most comfortable on his Go, and it's just my first, let's say production experience
was that language. I've since done Kotlin, I've done a bit of C#, but Go is like the one I keep going back to, I feel most effective in executing. And that is one aspect I would say of what makes me as a developer. But I'm curious to hear what you thinks. Makes like a really good software engineer developer, however you want to label it. I think, well, first of all, I think well, roundness is what makes it first of all, understanding how the computers work. What does that mean?
What is an, what is an others? What is actually an others and what is actually an if and how does it actually work electrically? But. What is the matter? Because I I don't understand that I think. For example. Because all the languages that we've built, besides the one that we've discovered at least and London Calculus, all the man made languages are leaky abstractions on top of these machines. OK, so even though we built all
these like things, they leak. Like for example, how cache lines work and what does it mean to read and write from SRAM? And it's not just a made-up, it's not just like we, we try to hide it, but we can't. The other thing is I think of course, if you're like, if you understand networking, how does IP over IP work? And why do we, how does the cloud networking works like VLAN's and IP over IP etcetera.
And how does then to understand design, to understand project management, to understand now data sense, I won't even call this and just understand transformer. I think we this, this is what actually I think makes a good developer because there is no like the code itself is useless without it's other things. And not understanding your customer is also not being apathetic with your customer not being like just everything is just one.
There is no I, I, I don't split developers in back end and front end. Makes no sense. OK for me. OK, you can either you either write the program or not, it doesn't even matter but. Why does that split not make sense? Like are you fan of the full stack roles that people have? Or no, I just think. Just. Code is code, OK if you can. The complexity I think from this much more complicated than back end depends on the back end of
course. If you do like this large scale distributed systems and you have this, I think people misunderstand how difficult is to write a bite on this to be and to have guarantees on that. And then on the front end you have like, oh, so, so many problems. So the, the way you think is actually what matters.
It doesn't really matter if you can get a little bit more experience on this or on this, but the the the concept of like transferring information and losing like order of things, systems and even even in the guarantees and what can fail, what cannot fail, whatever is the same.
Do you think these abstraction layers, and I'm specifically thinking of what we've done now on the front end are thinking are making things more complex because we have frameworks and then we have cloud providers that like operate on specifically those frameworks and you have so many flavours. Honestly, when they react went to hooks like that was we have to go back now. Really. Yeah, I think I. Like I like it from a usage
perspective, but then it's. I mean, like few days ago I had to like chase this bug, this like use effect with like, I don't know, it's like had like 20 parameters. Oh yeah. And I was like, this is just a rendering. And now, you know, I was like, this is just how did you end? I was like, how did you end up here? You know, just ridiculous. The the the size of the size of everything.
The I think it's incredibly complicated and and the sad box is still Excel and just do Excel and validation like we still cannot properly do front end validation. I think. I think the whole tangent is just wrong. OK. I mean, I don't know how many times you've done, I mean, in the Earth like just a form and you have to just OK, this is this. If this is wrong, the e-mail is wrong or like that is wrong, etcetera. You just have to have feedback, etcetera.
And now, but what if the user, the user exists? So now I have to like, OK, I have to send that here. And then you do these, there are like 1000 ways to to actually, because effectively what you want to do is you have to propagate some state from the database. Yeah, right into the the face of the user. Exactly. And we are still doing it like we were doing it in the 96. OK. It's really nothing changed. Nothing changed really.
I think so, yeah. I think there there are literally no changes and we just like going in circus. Does it have to change? Because the fact that it hasn't changed for like 30 years is a bit ridiculous. But then again, if that's kind of fulfills the need that we have, then maybe it doesn't need to change. Let me give you an example. You know, I think that the very best interface that like I want the best ideas we have had in the last 60 years maybe is the Unix pipe.
OK, so the Unix pipe is no program knows how it's going to be used and no programmer knows how the program is going to be used, OK. But when you write something, let's say cut or tuck or the right, you don't know. We don't know what it's going to do, how the user is going to actually use this. And in everything else that we've built in the in the front end world and the front and back end interactions in this, they, a whole team has to know how a user is going to use this thing you see.
And there is no such thing as reusable code that just doesn't exist. OK, you have to. Like if you want to do the same thing, you can just copy some things, but it's not a thing that the user can use on another website, you know what I mean? It works in the same ecosystem, but otherwise not. Your team basically has to decide how user is going to use this program. Whatever JavaScript program or back end, whatever, doesn't matter code this code how it's going to be used.
And that's why I think we're kind of like stuck in this local minima of OK, that's the best we can do with this kind of interfaces, OK. But I think that's that's we cannot progress much there, I feel. Interesting. For example, now we're with a new new kind of interface, like not only voice, but imagine 22 graphical programs. How do 2 graphical programs
interact At the moment? Let's just abandoned websites and they just have two programs like, I don't know, Photoshop and Slack. OK, so we have Photoshop and like, how do you how do they interact? Well, basically through a clipboard, screenshots. And right there is, there is no. And imagine how do you do that? If we had something like graphical Unix pipe, we just don't have that. No, we impose structure
absolutely everywhere. And that's actually what Unix pipe works because there's no structure. We just don't let, don't impose the program doesn't impose structure on the user or on the other program. It just text. So now I think with language models and vision, language and vision models, etcetera and vision models, we can do structureless communication between programs, between graphical programs. So that's why I think the whole forms and events and like blah,
blah, blah. I think it's, it's OK. But I think that's as good as it going to be. It's not, you know. I mean, they do serve like a purpose which is very isolated within those applications. Like the example of Slack versus Photoshop, I don't think there is much need because they are owned by different organizations. So there's no reason to coalesce. No, but for you, my as a user for me, yeah, yeah, but that's what I mean.
So now in those two organizations, a team has to be formed and they have to create an interface structured. And then I have to say, OK, where are we going? How are we going to communicate? And you as a user, like somebody has to decide for you what this what the possibilities are of this communication. While I think we have to go to a place where, well, you actually have infinite possibilities of
how to use your programs. It could be a game that you wanted to interact somehow with a bot that you have made. Yeah. Now, now that's not either you have to like just take the screen and and hijack the keyboard. But we should come up with like interfaces so that the programs can do that themselves. Yeah. Right now, I didn't even think of that because everything is like it works in isolation, it
works within the application. It doesn't cross the boundaries to other either physical things or other software things and that's it. But it's also because I like everything is driven at the end by money, right? There's no reason for adding that to user experience for things to merge and interactive synergize if there's no financial incentive at the end of the day.
Yeah, it's true. Well, but the, the things even even like open sourcing, like volunteer things, just think about how hard it is for your ID to interact with things in around it. Like you have to get like plug insurance and somebody has to write a play and the other thing has to expose some API to use it. And that's like a shame. I think that's like if you, if you use some, you know, Acme, the editor Acme just it's a very old, it's like a mouse is this yellow?
I don't know a rock bike uses it and but it's you basically have your text editor and then you have commands inside of it. You can just execute with the mouse. Basically you can select a bunch of text and you can pipe that to, I don't know, a grip or something or and can open a new Windows center. But the idea is from the editor you interface with everything around it and that Unix pipes
actually make that possible. But if you use visual code or something, you just can't even between visual, between the text, the code and the the terminal below it. It's not trivial to interface between those two things. And that's why I think it is the same on if you on the web or everywhere, if you have like, if you want to search, imagine you want to search for a flight, but at the same time you want to actually see how close are hotels to this?
If the if the some hotel website doesn't offer you both of those things on the same page, you can't do it. You have to like select like and that you see what I mean? That's like it's just that's as good as going to get the whole frameworks and etcetera. It's not going to solve this particular problem. Yeah, interesting. Like for me, because I grew up with, I think technology, technology at a stage where there were already abstraction
layers. My first production experience was on Google Cloud, for example. I've never run software on bare metal. I've been responsible because I I started my career in operations, but when I was moving to software engineering, that's when I started with those layers of abstraction already with front end. I started with React and I was like, OK, this is really cool and these are how the components
fit together. But then later on I got experience where it was just go go HTML templates and vanilla JavaScript and man, this is so much more performant. It works like a charm. We had a lot of AB testing and it executed really well. Like I don't know which abstraction layers are harmful or helpful because I do feel like some stuff makes me more productive, but it's also because I don't know what it would mean to kind of run
without. Like I ideally I wish the browser is just a virtual machine that can run my program and not this weird rendering engine plus all these other things. If so far though, I I react was much better than what we had before it right? Which like it seems at least the way you can have many people working on the same project, it was just much, much harder before the Angular React age. I think we had like Backbone and what did we have met or from the other stuff at the time.
And so in that sense, it was absolutely progress to have this abstraction of well, going back to PHP of code and code and data in the same place. And you can manipulate both very actively, right. A big problem was that because it was so unopinionated, there were like 1000 ways to do state and that was the the community conflict forced a lot. And then that led to OK, we have to kind of like try to find a common way and then just thinks when bad place.
But it started like first of all, the, the the the idea was, well, the Dome is we cannot re render the Dome so much so it's slow. So we have to render only the thing that has to be rendered. Yeah, if you look and that was the case before, but now the Dome is just ridiculously fast. And also a lot of the you can do a lot with the browser's own just possibilities, Yes, you don't need a lot of the thing
you we still have not solved. So if you don't abstraction about abstractions in OK, can I write faster code or better code? I think you can do better with the browser, but can you do something? Can you have a lot of people working on a project that's still not solved? OK the the The Mirage of like let's reuse a component which is just impossible. Like you have to people start parameterizing it. Or try. Yeah, absolutely. Have you seen it work? Like actually reuse a button.
Yeah, to a certain degree. I've never seen it. No, no. What is the? Why doesn't it work? I oh, first of all, because of AB testing, OK, it's really because you're somebody comes, I want to make this red and they're like, OK, do I forward the button or do I parameterize the button? Yeah, parameterize, that's how it goes. Yeah. And then they keep like, I want it to be a little bit In some context, I want to be like this. In other contexts, I want to be like that.
And because they can't change the patterns component, they have to. And so they keep it keeps piling, and then the end it because it's like monster. But is it because the, because I would say it's them because the design system, right? That's when I would push back and be like, this is ridiculous. We don't need a million variants. Of course, yeah.
But AB testing does not allow you to do that because somebody says, but what it brings more money, OK, so you cannot push back on it. You have to be, you have to have a super strong design leader which has to be able to say no to money and then. Like even with a few variants at the end one wins, right? So then we use that one? Or do we want to continuously? Keep because no, because you don't know if it's worth for the other ones. Really. Well, we have it in context.
Like let me just look at let's say I have this X. Oh, sorry, let's say I have this X on the in Zebia's logo. And then in some contexts you want it to be read. That doesn't mean in the in all contexts it has to be read. Really. OK. Yeah. That makes sense. So that that becomes like it's, it's such a, it's such a difficult thing to actually say no to this experimentation. And rightfully so, right? Because you don't know actually.
But if if that's the experimentation to such a degree where you do it, let's say either in in a phrase or in buttons, then how do experiments not class with each other but. They they do well. That's why I have like go it like white on white. So some team has the logo to be white on a black background, somebody else has it black on white background. And then of course, there's like some interaction between it's always like white on white or
black on black. And you do so you have statistics to actually see this this happening, OK. Yeah, but even when like on a button level you can AB test but also the components around it like things influence each other. I yeah, absolutely. No, no, no, that's I don't it's fine. People do it. I think that's like a waste of time. This not a waste of time obviously, but I think people's time can be better spent on making better excel. Yeah, fair.
I mean, if that's the level of degree, then yeah, I agree that your list of variables when it comes to a single component is going to make that super specific. And it's not easy to plug and play in a different context. That's but The thing is when you have like a list, you have the same problem. Like how do you like you start like, well, sometimes I want the top, the head, the the head to be a little bit different and then it doesn't fit. Then your mobile have to be like this.
So it just keeps the the especially about the things that you use a lot. I think it's really hard to actually make them reasonable. And the other ones you don't use at all, like they're not. There's no point because so it's like the only visibility matters for things that are actually going to be used for like weird use once, it doesn't matter.
But I always. Have this discussion with people that and especially back then when I did more front end, it's like we need to make this more reusable, right? And I'm of the mantra of let's just copy and see if we have another copy and then we see what's the common? Well, that's the rule of K. You have to have K, like you have to do something when K reaches some number. Yeah, For me, it's like usually three. Yeah, same. And that's OK. I think that's OK. Let's do it.
Let's let's see what happens when it's three. And then we can decide to, I think, I think that's the right approach this. This like pretending to see. The future first of all, you don't even know what you're writing. You don't even know if people are going to use it. You don't even know what it is as you start with something until and even the whole team, they have to like clash and somebody have ideas and somebody like they. Just like, not like.
It or somebody like something else and then you talk to users and then well, that's not actually what you wanted or what they want, so you don't actually know. Why would you try to make it reusable something that you don't, you just don't delete it just makes no sense. I agree. For me, then what makes someone really good in a team is this flexibility and kind of more practical mindset. But I do agree that the more you love like what you're doing, the more also your output matters to
you. At least that's what I've seen some people do. So then what they want to create, they do want elegance, for example, which I think is very subjective. And they do want reusability, even though it might not matter because it might not be used. And that's a hard conversation for me. Yeah, I mean. It is kind of because it's like it's just you have to challenge their values. Yeah. So it's like telling a vegan person that meat is good. Exactly.
That's how it. Feels, to be honest, I know. Yeah, it's the same with. When you're a parent, but it's the same if you challenge somebody else's parenting methods. It's just it's you get into a territory of it's really hard. So a lot of people, by the way, use experimentation to just tiebreaker. It's like, let's just let's just do it. Let's just test it and we'll see, right? That's what I try. It's. One of my one of the things I have in my pocket. Yeah, yeah, yeah. But it's also a way.
Out. I don't I think it's I mean I've been in this situation a lot of times and sometimes you you have to it depends on your personality, right. You'll be like, let's just see it's OK that's what they want to do that's what they want to do and you have to if if you can't convince them, I I don't like the commit. Like what? Disagreeing, Yeah. Disagreeing. Commit, I think, but in the end you're just like a person in the team as well.
And it's much better for somebody to do something that they enjoy than for them to do something they don't enjoy. Yeah, in a sense, sometimes you also have to say we just then you just have a time constraint. Well, what can you do actually in two hours, whatever the number is. And that actually forces them into. You cannot, Yeah, solution. Or you can all say like, look, I just promise you, just write, let's write it like this.
And then we'll absolutely put time in the calendar in the future to fix it, and then you defer. Yeah. There is no. The thing is. There is no good solution to that. Because it's my opinion, there isn't nobody. None of us knows the future. Yeah. And none of us knows it's even if this actually is going to be used.
So you can actually agree on if this is used more than X, like the actual actual next time we use it, we're just going to abstract it. But in the same time you also have to push back on unnecessary abstraction. Exactly. So you can't. It's so natural to abstract, but the reality is like with the with the electricity of the if right that you can't, you just can't. Everything leaks. Everything you think leaks a lot and and people people have this bias to elegance or to but the truth is that.
Even. I mean even things like. Let me see what you you might think. It doesn't leak with IP, OK. The Internet Protocol itself leaks and and TCP, particularly the way it controls its bandwidth, it leaks so much into the way you make web sockets. OK, you might be, oh, you have web sockets on top of this, but they are in the even it leaks through the libraries that you use to manage the web sockets because there are things like
half open TCP connections. So you you're you think it's open, the other side doesn't think it's open. There are things like which is just ridiculous to the book. So that's why I have like heartbeat. And then you have what what about the wait, sorry, duplex and etcetera. So can you, you you send the thing, but doesn't come back, you know, so even you try to run away from it, but you have to it it leak to accommodate? Yeah. It just leak.
What about when you have like multiple, because on mobile you have like multiple networks. Can you connect to, to multiple paths, etcetera, etcetera. So you have to, you have to push back. Like at some point you have to be like, that's not the way You can't, you can't pretend there's like a just a reality. You can't pretend that that's not going to happen. So when it comes.
To then let's say forming A-Team because I feel like these conversations are helping a group of individuals become a team. But do you take into account this, for example, when you're hiring people that you have kind of a similar mindset of how do we execute and what do we have like opinions on that differ which matter or where do we align I. Think the most important thing for me when I for a team is to to have like a shared sense of what actually technology is in our purpose.
Like in in our team, there are people that are like language article that zealots. They just like they do they want to go to a company because it's using the language that they like. Yeah. So I just really tried to stay away from them purely because what you want is to have people that are interested in the problem that you have. And technology is the thing it's just called it doesn't really matter at all. Yeah, so. The abstraction thing.
As well is a similar problem like to to be able to understand when to do it and when not to do it. So I definitely think that's it's important to when people are too far away. It's like the vegan meat thing. Sometimes it's not going to be soft, especially when people are like super, super convinced of something. So that's also important to just when you talk to somebody on the interview is to understand can they change your mind and can
you change their mind? Yeah. And so if they go in the conversation with as if you're talking to a wall, like it's immovable. So you're just either wasting time, it's pointless. It's there's no point. Yeah. So if you have a person that can change their mind and if you have a person that is interested in the problem, I think it's OK. But if you, because they can be, it's OK sometimes to argue because of course you're not always right. So it's healthy. Yeah, yeah.
So it's even better you. Want to have somebody that actually helps you right to teaches you and ideally this this. Language said that that kind of stuck with me because I say I told you I'm very fond of go as a programming language. I also love problem solving so then the the match, the ideal match for me would be both right interesting problems and with the language that I feel most productive with because then I can solve those problems faster.
I have a hard time starting things and then this hump of, let's say, learning a new language and getting to a level where I feel as productive, that for me is like, doesn't feel nice. It doesn't feel like I want to do that, even though it might be beneficial for me as an engineer. I Yeah, I see. What you mean first of all, now it's very different because you just have a cloud and GPT and then it's just like learning and you anything. Yeah, it's just so nice, but it
feels like. Like it might accelerate my learning, but I still have this inkling of I don't know what I don't know. And what if it's wrong? Yeah, yeah. I know what you mean, but depends on first of all, depends on languages.
Like for example, if you learn a new, if you have never done list for Hasco, I think it's great to do just for like it's almost like having a subject like, you know, like some languages have like cow eats grass, but the languages eat cow grass and cow grass eat, you know, like if you, if you learn all the languages that are like they're about 40% of language cow eats grass. I doesn't.
I don't think it. Like it helps you a lot in any but if you learn the other ways of thinking, I think it's very, of course, it's very hard. It's much harder, right? Like learning Japanese Arabic or you know, but I think it's, it's almost like our music. It's like the same thing. So you shouldn't try to stay away from it purely for growth because it just it would teach you to think differently. OK, about anything so that. Is not the same as.
Oh. I have to learn, OK, no Java, I'm going to learn C# now that OK, well, whatever, it's the same. You might be very brief in Java. You know nothing about C#. It's fine. You might be very productive in Go. You'll be just as productive in almost everything. You're just going to, it's going to take like a month and maybe half a month maybe. I like overestimate how how much time it's going to take. No for loop is a for. Loop, it's OK. Yeah, I don't.
The thing is you have to learn the EU syncratic things that they do like where they abstract where they don't abstract. That is kind of weird and. That also it's not actually a language, it's a company thing because the company has certain culture. Like for example, booking a Pearl booking was a Pearl shop shop when I joined. And Perl is like a multi powered language. You can write whatever you want in the like, in whatever way you
want. So when somebody comes with like a Java person comes, they're just going to write Java Perl. When a super person comes, they're just going to write C Perl. It's it's like this that's a problem. It is, but it's also part of the company sculpture to say what kind of what do we expect? Yeah, what the community is the way to do it. So it it has nothing to do with Perl.
So how you use it? Yeah, it's how the company uses it. And so it's the same when you go to a company and they you can, they, you can be doing go in a certain way or go is about it because it's particularly narrow. That's what that's the whole point. So I like it, yeah. That's why they made it. Like that, Condescending but. But but yeah. That's the point. It's very, very effective. Actually. My current company was Elixir Shop for when I joined and I was
like we can't do that. No, we can't. No, it's too. Well, having weird business rules in functional language is just such a pain. Yeah, You just pretend that you can. It's just everything is correct. Everything is correct. And then we're like, we're just moving to go. So we just, like I said, like we just rewrite everything and go. It was like 2 months or one month or something because.
And all of a sudden because previously we had this like heart split between front end and back end developers because. It was almost like a gate. Only certain people can write the next year. Yeah, well, literally nobody was writing go before, and nobody has done any go. And I said we're just going to go, and in a week everyone's just writing go. Isn't that great? Yeah, that's why that's the. Point of the it's great and then we just rewrote everything now all the Liverpool became full
style developers. Oh OK. And it was just done. So they also became. Comfortable enough to do the back end. Yeah, yeah, yeah. And. Then the other way, it was just like we moved to the same time to React Native and to and to go. OK. So yeah, I think that that it's a it's a great language in this. I don't think you can do that with other languages. No, I don't think it's possible to in a week to get like people productive in it. Exactly. Yeah.
Do you think? Full stack nowadays, like let's say Go as a back end language, then then I can see it. But with other languages because of, let's say how wide you can go and because of how open and flexible this toolbox is, and you have to get used to the conventions of the organization. It becomes harder and harder, right, cognitively.
And then you also have layers of abstraction that can either make things simpler, some cloud stuff, but also more complex, some stuff that runs on the cloud. Then it becomes harder. And full stack is now also evolving. I think with the role of AI,
it's becoming a lot, a lot. Yeah, I think like, look, especially with let's let's, it's true that to what does it mean to be full stack means you have to know so, so many things, just so many things in the end, I think most of them are the four loops are 4 loops kind of thing, but. It's becoming impossible. Basically, to do that, to be on top on on top of all these things that are just constantly
changing, it's difficult. I still think that the most like you have to start like just dropping things. You have to be like, what is actually because now, now let's say with let's say a new framework, you go to a new company and then they use whatever view instead of it. And the if you think like, do you actually know V8 or not? Yeah. Do you know JavaScript or not? Do you know what is fast and what is low? Do you know the event loop, etcetera?
It's not. And then after that, using language models, you can really transfer between all these things and you can even like paste what is CDO math? You can ask it and it's fine. For this particular stuff, it's actually OK, because like this is the average of all everything that they seen, right? So I think. You should as a full start developer, I think you should really stop looking at just frameworks and you should really look at technologies and, and really I, I think actually AI is
going to consume. For me. Particularly consume maybe like 50% of my time now. Oh really? Yeah, just. Playing with it and making. Things and not prompting, just making things like products. Or what do you mean? Just make neuron network that plays go but just a small 1. Whatever it does, just try. Just play with it because I think so. If you think of AI as. Just like, oh, this is like a tool that whatever. But I think of it more as a just a new kind of programming
computer. So it's like to learn how to program these machines. That's what the transformer. This is a differentiable computer, self programmable differentiable computer. So how you have to learn a new kind of languages to interact with. I'm not I'm not talking about Bytorch. I'm talking about. You know there are. Compilers that can compile, compile weights from the transformer that can do certain things.
So this is what I mean to actually program the transformer is it's just a new kind of thing and and if you want, it's a new completely new language, a new a new paradigm, the first new paradigm. So if you want to be a full start developer, I think now is to learn how to make these machines and how to program these machines. Imagine there's like a new kind of computer that you just have to program that just didn't exist.
It's and the the old stuff. Now you, you can use language to transfer because all the all the other stuff is basically the same. So and you can use language models to just help you just move between all those things. But the, the basically the limb that you're missing now is AI. Interesting. So. The the rest I think is like kind of like static and and it's like completely running in service.
So I don't worry about that. So I think the modern, at least the the one I want to be is supposed to develop is, is you have to be very, very comfortable with making and solving actual problems with, I don't know, state space models or Transformers. So just the modern, which are the modern technologies. Interesting. How are they going to? So I'm always wondering, because this new technology came out, I think it was late last year. And now we're here almost a full year later.
A lot of things have happened and a lot of things have gotten better, right? I talked to people and they're like, well, I saw much hallucination. It was really bad at programming, so on and so forth. I'm like, when was the last time you tried it? And they tell me many, many months ago, I'm like, you should try again. Because things, things evolve, and they evolve very quickly. Yeah.
Yeah, I've also told this many times on the podcast, but I always kind of idolize people that start their own company and do something with it. And for me, I think this technology is going to be really disruptive, right? Because people say always all this is disruptive and so on and so forth. I feel like this is going to stick more so than blockchain, Web 5 and other things that people are working on and that were more of a hype let's say a few years ago. I feel like this one will stick.
There is hype around. It there is definitely hype around it. No, no. No, and people are also getting sick of it from a developer and users perspective. But I do see value in some aspects, I just don't know where it will stick. I feel like education is a big component of it, yet there's dangerous because of hallucination and because of like knowledge gaps. But I, I really wonder where it's going to be applied because that's where I want to be as well. I feel. Yeah. Yeah, I think.
Now where I am, I'm purely interested in it as a child. Yeah. So I, I am not even thinking about because it's just so I mean, when you're on the steep part of the exponent, it seems like there's just no tomorrow because tomorrow is yesterday. So you you're like we're in this stage where tomorrow is yesterday and it's like everything is just crazy and anxiety and etcetera.
So I just looking at it from purely like childish point of view, like just like playing with it and etcetera, trying to understand it because I just don't think we understand it. Yeah, there's like, I don't know who said this example, but they, they gave this example of oil. So when in the 1900s people do like light their candles, not candles, but they're like Night
Lights, etcetera with whale fat. And then when they start drinking oil, they start just burning the oil and it and that it's, it's replaced the whaling industry in like 2 years or something to disappear. But they were basically just burning it. So they were just burning the oil. And that's until we actually made the internal Commission engine. The only thing we did we thought was burn it. OK. So I think now we're just burning tokens and that's we're just burning it.
We still have not made the internal Commission engine with this technology. So that's why when you say I want to be where it is, I don't like this thing is still burning. So we it's really hard to say what actually it's going to be. Yeah. And I think the best way what the best thing you can do is to understand it. So in the sense. Of in the metaphor with the oil, it will be to understand.
Just play with it and see what you can do with it so you can maybe find the internal combustion engine or at least understanding properties so that whatever happens after, you can use it. Yeah, I feel like. Everyone is trying to find the internal combustion engine like continuously basically, and it's like an arms race, I mean. Reasoning is one way to say like let's not burn the the tokens, but I just don't know. Because it could be like.
This new kind of interfaces, it could be like this program communication thing. It could be even things like one network just synthesizing data for another network so they can interpret or like robotics, etcetera. So we don't know, but. I don't think we'll know in the. Next like two years or so. Oh, OK. I think well, the more it is that it's going to get like really bad with I mean, I was just talking that all all these investments in it, we have to pay for it.
Oh yeah. And like this, when the feed becomes like heroin level, you know, you can't just stop. You can't stop. That is when I think it's a big problem. So we have to be really cautious of that happening. And that's kind of like orthogonal to because people people will not try to find. OK, let's let's use that for some good beneficial for society. The possibilities of it are like immense, right? But as Jung says, the the stronger the light, the darker the shadow.
So let's see when you have like subtle. Well, I mean, there's already the the people have it as a romantic partners. And there's like some people commit suicide because it's, it's just really, really. And like, yeah. Like the way we use it now, it's it's not even that we're the burning face.
Yeah. So. You have to. Really position yourself in to separate the technology from the way we use it as almost all the users have like super shallow and kind of I would say mean, you know, like kind of exploit thief and settlement.
You have to. That's why I think if you spend time understanding and playing with it like a child, I think you are much more likely to go to the internal combustion engine than just jumping on the of course, you can make it to have the perfect recommendation that is going to like make you not leave your phone. How much you should should you delay the Snapchat notification so that people can just you just left the phone, they'll pick it up again Yeah, that's more the.
Harmful side, I feel like we are investing both with our time from a usage perspective as well as from just a knowledge perspective and trying to understand. But the more and more I think of it as a broader thing, like the planet is also suffering because computer is going to go upright. We're burning oil is the same as burning oil elsewhere for running these things basically and that. Is going to be harmful. For the planet, I hope it also shifts around and like brings good to society.
But as long as there's no incentive from a financial perspective, there might not be, which is destructive at the end. I mean all the all. The big tech companies have dropped their climate goes Oh yeah. So yeah, like immediately, instantly. Like they had targets. And then you saw Chatty came out and compute went through the roof. Yeah, and. They actually officially have done the Satya Nadella and and the Google guy forgot his name.
He also like everybody just like, no, we're just not doing that. Yeah, yeah, it's a. Race now. Yeah. Yeah. Like we have to. That's it. Exactly. There is like a definitely like a group of Silicon Valley people that they are building like. The machine got. There is no way there. It's like a religious. Thing it's not even, it's a spiritual thing and they're just going that way and they think it's going to save us, it's
going to save us from ourselves. It's going to save energy, it's going to solve aging, it's going to solve death, which is like that's, you know, and they're just going, they're just like completely just they don't, yeah, there's no, that's their combustion engine. Because. Yeah, because they also think if you don't the the other thing also doesn't work. Like the climate goes, we had for like, I don't know anything about the I mean, we were not on target. No, no, no, We have.
To do a lot, basically, yeah, it needs to be fully regulated. You cannot do business if you don't have ambitious goals. That's the only way it would work. But. Even with the the trajectory we're in, it was just not going to work out into 2050. So they're like, it's not going to work anyway. Let's just go all in on this thing and let's just big risk though, but. Big reward, yes, yes, so that's. I think the bet I don't. I don't know enough about about the subject to talk about it besides.
I hope it. Works out. I, I'm in the same camp. Like I feel like I'm not a subject matter expert. Like I, the tool that we're building at the customer that I work at now is completely in the sustainability domain, like seeing what companies have their targets, if they're ambitious and how are they meeting them, Basically giving overview of that to also steer. So that's why I'm a bit more like invested in this topic.
And it goes hand in hand with all the technology boom that we have where compute went through the roof. Like that's where I see it do harm for the planet. And yeah, there's only hope. There's only. But I do want to be kind of in that direction because I feel like it is disruptive technology. I don't think it comes often that we have something like that. I think that's the. First time since the industrial revolution. Maybe since industrial revolution.
I think even even. Even. Language level, you know, like the best technology we have is language. That's the first technology we have and the best technology we have. The reason why language is an important technology is because well, reality is is projected from our brain.
It's like simulated. So the only way two people can communicate is to symbolically, because I have completely perceived completely different reality and even in symbols like that's why language is like such a important technology for our species. And I think this is now like almost like language level technology. Yeah. That especially if it starts self accelerating, which I I don't know, it doesn't happen. It's already some, but it's at least in the last 100 year
computing wise. I think it's just the the first paradigm change that we see. Yeah, exactly. I've really enjoyed this conversation. Whereas stuff this was a lot of fun. I'm going to really listen to this and really zone in all the things you mentioned because I feel like there's a lot of takeaways there before we were bound off. Is there anything you still want to share? I just for anybody that is like starting right now, I I don't think they should read Reddit. Just just.
Just do the thing that you want to do. And I can just try to find joy in like the little things of programming. Yeah, I really like. The experimentation thing, I, I know there is joy in that, but I also know day in, day out, I don't do it often enough. Yeah. Yeah, it's so it's just day-to-day and it's just like I have, I have a meeting at 1:00 and then I have to do this thing and I have an interview like 6 and whatever. But if it's 10 lines of code,
just enjoy the 10 lines of code. That's also we're. Going to round it off there. Thank you so much for listening. If you liked the episode, leave a like. Let us know in the comments what you thought of the episode and we'll see you on the next one.