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.
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.