Unveiling Creativity in Tech: The Art of Research and Development | MetaDev 03

hi and welcome to yet another episode of the meta dev corner again i have boro with me say hi boro hi and today we are going to discuss this very interesting topic to us at least that's also very near and dear to our hearts considering that early on in our careers we've had a very interesting experience with a proper r&d process so what is r&d yes i can share my experience before giving the definition because the definition will be based on my experience my first three years of professionally wo

rking as a programmer developer were for an outsourcing company which basically we had like product managers and qa teams and whatnot and they would just come to us and say okay this is what you need to do and that's this is where the story ends so i did this thing for three years and uh then i uh have a friend who introduced me to darko and i joined my first r&d company and i actually saw the beauty of doing some research beyond just doing development so based on this experience that i have i w

ould define development as something that is the last step of a process where you just literally do what you need to do that is write the code and i will stick to that for development and for research so that's what i would say um the shortest definition i can come with i would say is um figuring things out um testing a few stuff uh searching online searching for clues and then making a decision i know this is very vague but i'm sure we will get into the specifics yeah like that's an interesting

definition and it's sort of very close to what i'm thinking you probably remember like one of my favorite sentences i keep on repeating this one that content creation is the final step of a learning process from one of my favorite creators out there uh salma so r&d to me is you know can be defined very similarly like if we define development as the final step of solving a problem the research part is actually understanding the problem understanding what is it that we're trying to solve and buil

d now that research part can be defined in you know many different ways if we're trying to let's say write a service of some kind understand what is the problem what is the problem that the service is trying to automate for example if we're trying to create a user interface research our users understand their needs and so forth before you arrive at the process of actually cranking some code and making things happen on screen so to me that's it like truly understanding the problem and then actual

ly using the code as tool to solve that problem yeah actually i would agree with that and i i would also say i i like that definition better because it's uh uh more aligned with research in general it's a looser definition than what i gave which was strictly tied to development but i definitely agree that um understanding the domain understanding the problem not just about development but in general speaking to users speaking to teams speaking to people stakeholders and ultimately make a proper

decision which at the end is just yeah turning in from a natural language to a programming language of any kind yeah basically making software happen you know but by that meme like turning caffeine into code and stuff like that you know the thing that pms especially loved using a while ago i'm not sure whether that's still the case but you know it was an interesting time anyway so okay let's maybe start first with some not that great examples of trying to solve problems when you're trying to bui

ld software now the usual way that let's say service-oriented companies and agencies approach to solving users or clients needs is like client throws something over the wall we take the thing on this side we're trying to solve it and you know there's not really proper amount of time to understand that problem to do the research and have you had like any negative experiences like that yeah um i mean i would not call it negative for sure but i would call it an experience and it's a very constraine

d experience yeah because it's one thing where you're working under a very specific set of constraints and somebody usually the client uh tells you okay you need to do x y and z and you just go and do it because that's a direct request from the client and there is nothing to debate here there is nothing to discuss or the client knows uh exactly what they need and um you just go and do it you just uh basically you are offloading the client is offloading um the development cycle in in a sense they

don't know how to develop assuming and they they are only offloading this part of the story and so um i guess yeah it could be considered negative experience because you are working under very limited um uh set of constraints but i guess the the most negative part about that is that it gets boring quite fast that's true so yeah you're just like you know in grant mode writing code or as some people like calling it code monkeying yeah yeah that that's actually a that's funny i had as demeaning as

that might sound so apologies if anyone got offended by that no i actually had one co-worker that uh used that title code monkey um or typing monkey or something like that but it's exactly that in my opinion pure development um is exactly that just giving the definition for the in the context of this talk um and when um so uh or actually yeah before going to the room i was just like oh my god i'm gonna do this research i the the one thing i i really liked about this um mode of working is uh it'

s kind like kind of like a gradual um moving up towards next the next step so i i would say something in my experience i would say i'm really glad i had that experience because i would never otherwise i would never be able to understand the beauty of research yeah so i'm also curious to hear your experience if you have to share a strictly pure development you know like the my bad experience example you mean or in general i i would say in general whichever you feel like sharing let's start with t

he bad ones i guess i i well i have plenty of those i i have luckily been part of r&d teams that actually did proper r&d work twice so far and like i know that people don't really know how to do it they don't know how to do it they don't know how to do it get those opportunities often especially around here so yay me but let's start with the bad ones anyway um i spent a large part of my career either as a freelancer or in agencies and as it happens there's not much of a research process to speak

of so it means that more often than not we don't invest enough time in understanding the problem we simply assume that this is the problem domain we just want some code and you know something that works in production turned out and that's it yes and it's cycle after cycle after cycle and it tends to produce this immense amount of technical depth and at some point it becomes like hopelessly entangled in like horrors unspeakable horrors and like you're essentially the fifth developer down the lin

e that inherited those like eldritch horrors and stuff and you have no hope in hell of understanding like all of that tangled mess down the line unless you invest some copious hours into that like let's say not hours hours is like really not accurate here i'm talking about months so you have to invest months to properly understand it untangle it and then maybe maybe have some hope of you know making the productivity cycle a bit better yeah i i definitely think it's a good idea to invest some tim

e in understanding the important issues that might be occurring and to make sure that it's a good investment for the company that's part of the market here and i would definitely share the same experience but you know one thing i really miss from boro in this in that world in the past things seem so simple ah yes they did didn't they yes and i i really appreciated that because you know you are just like working under heavy constraints and just do the thing yeah and there is nothing to debate abo

ut there is no need for any sort of advanced documentation beyond like basic emails there is no need for metadata yeah we'd be out of a job man i mean probably not but still you know so yeah i remember there was this quote i i rarely remember names this is my design fault in my brain but it it was something along the lines of men have a special way of complicating things um and uh you know the the word men obviously used to the human race uh as a whole but i i really like that quote again i don'

t remember who it was but um we do i mean if i if i look my career sort of like gradual progression i would prefer to keep things simple and uh obviously you know that's not that's not possible and um i'm really so one thing i'm not sure if i'm going to be able to do that i think i i really um i would not use a hard word like dislike but one thing i i really miss is simple solutions which it gets very hard as you you know progress and uh learn more things and just get into the philosophical worl

d and see that there is basically no good solution yeah i would hate to get into semantics here in the definition of words it's really not one of is the are we talking about surface level simple are we talking about something that's actually simple we spend the time to properly understand and break it down and we can like with a reasonable amount of confidence call it simple it's a great question i i would say the when i use the term simple i used it in the sense that first my knowledge was limi

ted so um you know um you just do the thing based on what you know which is very small and second you are working under heavy constraints and you don't have the authority to even question those constraints and you're not even expected to yeah i mean the first company was literally here is a task in english or macedonian go write it in java yeah or c-sharp or whatever and uh things felt so simple back then um i i know obviously i missed on uh a lot of things that were happening behind the scenes

yeah but um you know as you go behind the scenes we'll talk more about research as we get into that and how it fits into development but as you go deeper and deeper you just keep opening new set of can of worms let's put it that way yeah the deeper you go like more eldritch horrors like emerge so it sort of comes with the territory i guess it's interesting that when you're like you're like you're like you're more green younger in your career like you tend to understand everything in more simplis

tic terms like more often than not we just care about the tech throw us a problem that's you know take your whatever we can turn you out a solution we don't care about like what lies beneath we don't really care about the business logic or whatever let's like the business people care about at least i was like that for yeah quite for a longer time than i care to admit way probably most of us yeah yeah so it's i guess as you progress in your career like the term simple starts to take on a differen

t meaning i suppose it does and um uh i mean this is not to say that i i don't enjoy you know these discussions like metadata but it sometimes feels like the more knowledge you you get uh the harder things become um and uh there was another quote which i don't remember at the time but um it's just yeah things are not becoming less complex the more you learn and the more you acquire knowledge but i think on the opposite they become more complex and um you know even when we have to make a decision

in some case you just like well a decision has to be made and i made it um but it still doesn't matter and i think that's the thing that's the thing that's the thing that's the doesn't feel right whereas before we had this let's say you know amount of knowledge it was very simple you make a decision and you're just happy yeah and uh ignorance is bliss i guess yeah that's true like but that's up to a point up until we actually encountered and we got the freedom to hey here's a problem research i

t you have like an unlimited amount of time like it was at first it was shocking yeah like i couldn't you know okay what do you mean i have an unlimited amount of them well you just have an unlimited amount of time and you know go ahead and solve this problem which was an interesting experience do you remember like what was the first thing we actually built with that amount of freedom because it's sort of fuzzy for me yeah the first thing that comes to my mind okay so just starting with some con

text yeah the second company where i joined and i don't know which company that was for you was the third fourth i'm not sure probably third okay so for me yeah the second company i i got to work with uh darko and uh marian karovsky on on a team which was probably get him on an episode hopefully we're hoping for that it's a tricky one but um so we were working on the three the two of us were working on this team which was basically supposed to do like cutting edge r&d and uh some more context th

e product was building a building an advanced video player on multiple platforms beyond just the web so we also had a desktop client and um client on mobile devices back then so uh this is the first time where for me where i experienced what research really means and uh literally like what darko said something along the lines of this uh ceo you know when i when i interviewed for the job was basically you have unlimited amount of time to do research and when i was like okay i i i don't believe th

is is true but i i will buy this yeah um so and we did a lot of interesting stuff in my in my opinion uh one of the so i'll go back to your question after i gave this long context um first thing i remember working with you was um so we had uh this uh like i said video player that was based on the np api i think that's long gone yeah this is a long long gone thing like it's been deprecated quite a while ago say firefox version circa 4 or something like that what year was this about oh um i think

it went along with uh flash and i would like to say 2013 14 probably something like that yes so back this was back in 2012 when we did the work and i remember even back then there were some deprecation notices yeah yeah yeah but they were very clear about hey this is going to die you shouldn't use this but you know yeah when has that ever changed our minds yeah and so um we had like this video player based on np api basically a browser plugin that allows you to play videos in a much smarter way

i think back then correct me if i'm wrong but i think html5 and the video tag were still under heavy work in progress so well they were they weren't exactly a worked in progress they were standardized but not every browser right had a the the same idea about the implementation so we were struggling with about a bunch of codecs with a bunch of container formats and apple as usual were being smart and like safari was you know very special about it it's it's really a painful point for me i don't wa

nt to get into it so please go on so the ceo comes to us and says we need to find a way to speed up the um um video skin playback process and you know this was the usual way how things got communicated to us and we were just like literally full autonomy freedom and you know just go and see what is there on the out on the field and so i i think as far as i remember this was the first collaboration with you where what we did was basically we used the lib area ah yes hope i pronounced that correctl

y yes area and area to see was the cli utility if i'm not mistaken yes right so basically area is a torrent client which uh http and torrent client right did a bunch of exactly additional stuff on top yeah but in our use case we used the torrent functionality mostly the idea was okay one way to speed up uh video playback was uh you know we would reduce our uh server load uh by uh introducing clip area into the mp api plugin which would you know if the more clients there are viewing the same vide

o the more uh they can distribute among themselves the content that they serve so this means faster playback uh in some cases obviously not in all and also less load on our servers where the actual videos were hosted um so that's the first thing i remember working with you but i know we did a lot of more interesting stuff after that uh with the gfs probably we'll get into those as well yeah it was i i think that was our first collab like we were a weird thing like it's not that we started off i

think like with the idea of building an r&d team especially it was really we were a team of like sort of a ragtag non-structured team that actually got the tasks that nobody else wanted and we're i guess we're built that way that we like weird problems i suppose and one thing led to another we started getting into rfcs or you know libraries that were really low level that you know had to you had to transcode something to something else you had to stream in a very special way and we had to do a l

ot of things and we had to do a lot of things and one thing led to another we became an r&d team so sort of by mistake but yeah that was probably our first collab so the the point was that each of the team members at any given time did you know not they didn't really we didn't really work on the same projects we worked on different things and if there was an overlap we got to collab and it was really cool it was an interesting way of working so the thing that we actually did was we did a lot of

it had to do with um streaming to the browser to a plugin that was supposed to be a part of a paid sort of like monetized video platform with drm and all the with yeah yeah with you know drm before like we got wiser about that hey drm is not going to work as you imagine it's going to work i mean people are still trying but you know come on man drm isn't going to work anyway so uh sort of protected it was monetized but we started hitting a problem where we didn't have enough servers to go around

and cdns weren't an option for some reason and i sort of i'm fuzzy on that one list and we had the idea of using like peer-to-peer stuff because like we had a bunch of connected clients in a closed network that was already you know sort of paid and there was an expectation of them to have like at least reasonably fast connections so we had a bunch so we could sort of hook into that and you know since the paid platform is controlling the narrative we could probably sell that in some way it was in

teresting it worked pretty well i i yeah i mean yes the uh our our solution was basically you know it shipped to production and it really did its job um and uh you know this goes back to the how we started the discussion of like how we started out with the predictors and how we started out with the custom computer understood and uh the uh the the working cost of building a system uh which would be the most expensive kind of machine um if we sold it out and and and but so this was the the first s

trategy in terms of what we could do with it and then and uh only one that you could do was uh the nft uh versus the nft uh which i think is the most nice challenge yeah it's kind of like a new one this new the reason why we're still the process uh so yeah this is the tool that we built obviously my thought exactly because we've told the story but we didn't really get into the process and probably the process is the most interesting part of what we're trying to say but but i think so far at leas

t we based on our experience make a clear distinction between what uh pure development was and what uh our research was and what you know how you synthesize those yeah too so maybe we can yeah chat a bit about the process on the research side of things absolutely so okay let's say like imagine this either let's say me or our colleague caro hi caro or the ceo comes to you and says like hey i want you to build me a you know let's say a drm player that's going to work inside a web browser that's al

l you get as a requirement and you have an unlimited amount of time go yeah uh that's exactly how it was and i i would also like to mention a quick anecdote the ceo was referring to us as the three uh little princesses no that was the sysadmin dude maybe both of them yeah possibly yeah we were special yes uh special um so but for the process itself okay you now working having worked remotely uh for a very long time um and dark as well we'll probably dedicate a whole session to this yeah at some

point so one thing i really miss from though from that experience was it was very organic and uh you know we would like yeah drink our coffee or play mortal kombat on the playstation or whatever and somebody you know darko would come with an idea hey we should try this and i was i was just like you know leave the coffee and just sit on the computer right away um so basically i think most of the uh hangouts were like that where or we would you know have some beers or whatever within the company p

remises and most of the interesting bits actually happened outside of the computer and then you just sit on the computer and do the stuff that you need to do which is the development part but i think for the research part you know darko and darko and darko and darko and darko and darko and darko and darko and darko and darko and darko would come in and say something like um have you ever heard of leap area and i'm like no what is that well it's basically a torrent library i'm like let's go and f

igure out what has what can we do with it you know and we just like sit and dissect it up to the point where you know you start with reading documentation obviously um code examples um try some build some very small proof of concepts. I remember Darko built this very tiny server on his computer and I just cloned it to my computer as well, and we just started both services at the same time to see if they would discover each other, like a torrent within the peer-to-peer network. And so you see the

result, hey, I see you and you see me. So this is pure bliss, it's pure joy. It's a great feeling. It feels like an accomplishment. So a lot of smaller things like that, and then you just take all of the small things and you just integrate them within the bigger application. But like I said, just to reiterate, I really miss... I think remote will probably never be able to capture the essence of those in-person collaborations where you're just like water cooler chat and do some peer research tog

ether, see what works, see what doesn't work, and build on top of that. Yeah, for real. I mean, yeah, that's for me, it's... I usually, when, let's say, similar scenarios, somebody throws a problem at me and I start by researching conventional wisdom and then I start researching the fringes. And see why the fringe ideas might work, might not work. And try to adapt most of what's out there towards what we're trying to actually achieve ultimately. And I don't like reinventing wheels at all, but I

don't... I'm not a particularly huge fan of shoehorning things either. So if there's something reasonably low-level to use, I'm probably going to use it. But if it requires an entire framework and, like, have a server cluster somewhere, like, I'm probably not going to go with that. Yeah. Because I like my tools simple. I like, you know, I'm probably... I have probably mentioned this, like, a hundred times so far. I'm a huge fan of the Unix philosophy and I'm a huge fan of how things were done ba

ck in Bell Labs. Like, essentially, have these small utilities that can pipe with one another so that you don't ever have the need of, you know, producing very complex software just... from the get-go. You can solve it in very small pieces, pipe those pieces and produce, like, some more complex software. I think that's a lost art by now with, you know, us trying to over-engineer pretty much everything. But I digress. In general, like, try to create a pipeline of smaller stuff that actually... th

at's close enough to solving your problem. And when you hit that limit, when you've piped enough things and you can no longer, like, shape those things towards your problem, write something custom on top. To really fit into the entire, like, problem area and offer it as a solution. And I think that's what we did with the area thing and after that with the... Was it libvlc that we used? Yes. Initially, we used libvlc and... The CEO at one point comes to us and says, we want to be able to offer ou

r clients to be able to view videos in a frame-accurate fashion. Oh, right. So this was one of the most vague requirements. And we were like, well, okay, we use libvlc, which is basically, like you said, you know, another abstraction on top of libffmpeg, libff. So yeah, over-engineering. The cycle continues. But libvlc basically abstracted a lot of stuff and it did not give us the option to... It did not give us the control over the, you know, the video codec that we needed so that we could say,

okay, stop the video at exactly frame one, two, three. Yeah. So we did the transition or migration from vlc to libff. And at this point, you know, and this is interesting, actually, because what you said about research beyond just, you know, obviously we did not... We thought reinventing the wheel by implementing your own video player would be, you know, definitely impossible or spend a couple of years writing a video and audio as well, encoder-decoder. So we decided to reuse this and obviously

open source. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And at this point, you know, the research itself was about... So libff back then, I don't know if things changed today, but it had no, basically no documentation. So the only thing was you just go and dig into the source code. There were man files, so, you know. Yeah, but very high level. But no, as far as man files go, you know, it's not very detailed. And then you also have... So libff is basically a framework that has a lot of... A

support for a lot of different formats and codecs. I think the one we mostly dealt with was mp4, if I remember correctly, back then. Ah, yes, mp4 and something else for Apple devices. They had something... Maybe QuickTime. Yes, QuickTime. Oh my God, I'm so happy that's dead. Anyway. Yeah. Yeah. And, you know, the whole research... So there is a lot of... There are a lot of different degrees to doing research. You know, it's one thing if you do... Yeah, browsing through RFCs, obviously documenta

tion, checking out code examples. When that is not an option, you're dealing with an open source project, dig through the source code, which is much more difficult. Trying yourself to build this picture around the, you know, the code base, of libff and whatnot. And then there is the other... Another perspective, which is closed source. I don't remember the exact code that we were working with, but it was basically closed source. I remember we received tons of documentation about it, but it was v

ery high level. And so this is all blurry. It's very blurry. I remember that happening, but I don't remember exactly what it was about. I think it was... So the client... Client was Technicolor and they had their own video format or whatever, so... No, they had their own container format. Or was it a video format? Maybe both. It's very blurry. But I remember us... We're old, I mean, come on. So at this point, you know, when you're dealing with closed source and you just try to understand somethi

ng, the only thing you... The only tool you have basically is reverse engineering. Yeah. And... This is the most, in my opinion, the most time consuming tool, but the most satisfactory one. Assuming you make progress. Yes. You can hit a lot of walls when you're trying to reverse engineer something and you have to be like really persistent. Exactly. So, and at this time is where I, you know, when personally, I saw the beauty of what research really is. Mhm. That there is a whole new other world b

eyond just development. And it was fun because, you know, you are just like collaborating with different people whom you share biases with. Yeah, of course. So I think genuine curiosity is very important for this. Yeah. But you are learning a lot. I mean, for me myself, I feel like I learned, I came out of that company, like with tons of knowledge. Mhm. Both about technologies, but also about the beauty of research. Mhm. Obviously it, you know, it was this progression from a very simple developm

ent-only world into R&D, where now you are faced with, well, I know about this solution, but is there a better solution? So you are to the mode of doing, you know, you're basically habituated to do more and more research, whereas previously it was a different habit. Yeah, I am still off, and sometimes I've been, you know, judged as being too slow with building something just because of that habit. Like when I'm trying to work on something, I'm trying to truly understand it first. And yes, someti

mes that might take more time, but personally I think it's worth it because once you truly understand the problem, any addition to sort of like additive problem to that core problem later will take significantly less time if you invest the initial time to truly understand the core of the problem. I agree from an aspect of, you know, companies and what companies are optimizing for. I definitely agree with that. That, you know, obviously doing research and before making a decision is much better t

han just making a decision. But I think also another interesting aspect to consider is the developer experience, or maybe not as a very general term, but mostly in the sense how and what does the developer feel like at the moment. Because I think there is this, to me it was implicit until a few years ago where, you know, like I mentioned, it felt like this huge progression. But at the same time, it also felt like I have this new tool in my toolbox. But it sort of paralyzes me up to a point where

, you know, I guess the biggest blocker for me, even to this day, I don't think I've gotten past that, is how deep and how far do you go research? So I think this is a very tricky question because, if you don't balance research and development, you know, it will obviously be either full research or either full development in the spectrums. But if you balance those, you know, up until some point, you have to cut it. You have to say, I've done some amount of research and I need to make a decision.

Yes, but that probably goes hand in hand with like you have an idea. And in order to do that, you have to make a decision. and in order to validate that idea you would have to try something you have to experiment with you know the practical aspects of that idea so this is similar you research something you try to build something with it maybe it doesn't work back to the drawing board back to doing some more research then try something next time it sticks and after that you can additively build

on that that is true and you have to take into consideration that sometimes you will fuck it up at the fifth iteration maybe well and like everything before that basically goes out but yeah that's not a bad problem to have because you're probably trying to solve something that's worth solving no no no yeah for sure i completely agree it's not a bad problem to have i will make the analogy with the toolbox so in my toolbox i had only development as a tool and only now i also got you back then i go

t introduced to research as a tool but now the thing is you are feeling so good when you are using the research let's say drill whatever and you don't want to go back to development yeah you just want to there there was this um or maybe even today it happens with me the problem with uh perfection how far do you go researching um when do you cut it when do you say this is enough info for going back to development so it's not a bad problem to have but i think it introduces more problems because yo

u know we started the discussion you know pure developer pure doing only development very simple world everything feels interesting not interesting but maybe everything feels um rewarding let's say and now you have a new tool which also gives you more responsibility and it's really up to you to you know decide when you need to do the cut and when you need to go back to development um so it's not making things simpler yeah yeah but you know it's the balancing act thing like perfect is the enemy o

f good and good enough is the enemy of actually good so yep exactly and um so yeah that's and you know after i got this tool in my tool college and after this i shut my channel and i startedenes computing i started learning that also i started reading too much but i need to change at the end so if you have any questions from today let me know in the comment box be sure to check out her uh, in my toolbox for me personally, I, you know, I just kept on using it even to this day. Um, uh, and, you kn

ow, I still meet some, you know, uh, let's say, uh, close relatives, like mostly older person, my grandmother, let's say. And they would ask me like very simple questions. Like when is the next bus going to arrive at this station? And I'm like thinking to myself, well, you can easily check this for yourself, but you know, and so, yeah, this, uh, you know, thinking in the research aspect, uh, definitely, uh, increases your pool of knowledge and, uh, your chance or your ability to acquire, to, to

even further extend this pool of knowledge. But, um, you know, uh, it's, uh, and, you know, you know, even when working with coworkers, like, you know, some questions they ask would feel like very simple. And I'm like, sometimes I would give like explicit feedback, like, well, this is, you know, one Google away or things like that. Um, but, uh, yeah, uh, I, I want to go to be, uh, to meta on, on the research topic, but I guess the next step is to figure out like, how do you spread the research s

pirit among people? So to me, this is, you know, this is a thing. I'm constantly thinking of, uh, um, you know, my sister or my wife, for example, who are not that tech savvy would be, would nudge me for things like my phone doesn't turn on when I'm like, have you tried plugging it into a charger or, uh, you know, like a very basic troubleshooting kind of, which, which I feel came as, as knowledge based on research. And like you said earlier in the podcast, um, trying to understand things at the

fundamental level. Um, so yeah, I, on, on the one hand, it feels really good to be able to solve problems, but on the other hand, I think it just generates more problems. No, that's true. There has to be a cutoff, of course, in order for it to make sense. Cool. So I wanted to ask you something like, did you ever have like any sort of comparable or similar experience after we start, after we stopped working at that company? I would say, so there are many things in play here. Um, first after this

company, I, uh, worked very briefly for another company, a couple of months. Um, and, um, after that I started working remotely. So yeah, since 2014, full remote now, almost 10 years, I would say I have not Um, mostly because, you know, when you transition to work remotely, there are some things that you're trading. So you gain a lot of things and also at the same time, you lose some of the things. So I think this experience and now I'm, you know, I'm very, obviously very habituated to working

remotely after doing it for so long. Um, but, uh, and I, you know, I, I don't think I would go back to, an office but i don't know things change so we'll see but i don't think that experience can be exactly replicated um i so you know obviously the company culture came into play so it was very light like very um kind of uh hacker style hacker hacker space style company where nobody micromanages you nobody cares when you arrive at you know premises or when you leave them um you know if you feel l

ike that i remember there was a playstation console and a lot of beers in the fridge and a lot of coffee so it was very um you know obviously a startup but i i would i would not say this experience is easily replicable mostly because uh also i've gotten older and um the amount of energy i invested you know yeah basically i would usually start our day at 9 or 10 a.m and then end up home at 9 or 10 p.m yeah so that happened yeah that tended to happen and obviously you know this requires a lot of e

nergy and it requires you having a lot of freedom as a youngster yeah and um um but i i have not been able to you know replicate the exact same thing but uh parts of that for sure like you know i really enjoyed the autonomy the freedom uh the ability to be able to do research um you know write research results document them share them with people make a decision uh those things for sure but the the whole kind of um you know the the whole uh structure the whole uh vibe to it i i would say probabl

y not reproducible so i have not what about yourself actually i did i had a pretty long running experience after that you probably remember that company that i did some assistive technologies and stuff like that i do that like was that a remote yeah position yeah it was okay so still similar but not exactly it's no not exactly like i didn't have many colleagues that i was in a physical space with i did have some and it was a very good experience with them but for the most part for the largest am

ount of that time i was pretty much solo it wasn't bad at all because like i had the freedom to truly research and understand the problem before trying to apply a solution to it and it worked pretty well it's not that you produce the perfect code we don't have the perfect code we don't have the perfect code we managed to screw some things up like significantly like we went through a couple of you know not big refactors but there were some refactors there were some really big walls that we've hit

but we sort of chose to trust the process sometimes it took a lot of time it's fine and it's also fine when you're trying to sort of explore and map a problem space that hasn't exactly been explored properly before and this was such a case so it's spoken like a true senior it depends of course but in general i see value in doing things a bit slower from the get-go in order to truly invest in understanding them and you know you as a person and a professional growing comfortable and accustomed to

problem space and all of it you know when you start working in a new problem space right you don't really understand the entire logic or the inner workings or the whys of that problem space you don't understand how the people operate inside that space right you don't have the big picture you just have a bunch of like tasks or tickets or whatever but you don't have the larger context and the larger context is really helpful in informing you on how to really solve a certain problem what choices w

ould be the right choices there so i would just like to round this sort of line of thinking with you know you're trying to you're you're primarily you're being paid to solve problems you're hired to solve problems and coding is a tool for solving those problems you don't really have to see yourself as a glorified typewriter essentially yeah yeah and it's a it's a it's a great story because um but you know at the same time like like you said yeah exploring you know i usually the first thing that

comes to my mind when i when i use the research is exploring dungeons mostly because i i played uh uh rpgs as a as a small kid um but uh and you know yeah exploring those dungeons or mazes or whatever uh definitely gives you more opportunity you know more more uh views more perspectives but at at the same time um i i would make the comparison here where going back to the previous topic about um you know working doing research remotely and then doing research um in you know in in person and then

doing research um in in you know in in person and then doing research um in an office without going too deeper because i think we might have a whole episode dedicated yeah yeah for sure um but yeah you know and i i want to use the the analogy of exploring dungeons or mazes um when i feel like in my experience when we worked in together in this company and we had the chance to um do the research together yeah it felt like you are walking through these mazes and then discovering things as a you kn

ow uh as a group yeah so moving together forward sounds like dnd yeah exactly i i did i have played like two or three dnd games in my life but it did sound it did look very similar when i when i played those and uh comparing remote uh there is this aspect in the remote which is i think quite tricky um asynchronous communication cutting feedback loops yeah so i would say it is nearly impossible to do um research as a group in in longer periods of course you can have like you know an hour pair pro

gramming session or whatever but uh it's not something that you know whereas with you and with um marion we were working in the same office and you were literally supposed to be there to do any work and you were supposed to be there to do any work and you were supposed to be there to do any work so uh there is no option you are researching dungeons or exploring or traversing dungeons as a group no other option and in remote i feel like you're mostly on yourself where you just like you know do th

e whole um dungeon traversal you come back with research results and then somehow these research results like a map that was explored needs to fit like with what you said in the previous uh discussion needs to fit with the bigger picture and the bigger picture is basically a sequence of different maps yeah but um and i i you know i i would not say i i prefer this type of work or that type of work i am just saying that they're different and um sometimes uh working remotely can feel can can give y

ou the feeling of feeling um you know feeling alone uh because yeah you're supposed to be in a group and you're supposed to be in a group and you're supposed to be in a group and you're supposed to you know run a lot of simulations inside your head run a lot of different scenarios uh you know basically exploring the dungeon or map or whatever and um then you know make decision based on that whereas as a group it feels like uh you know through through dialogue uh you are essentially solving a pro

blem together whereas the other one is mostly monologue um but you know then on the other hand uh yeah being in the office all the time definitely cuts a lot of the flexibility like having to take my kids to school or do some grocery shopping or um out of nowhere random i want to take a shower at 1 p.m which is not always possible in the office at least we did not have showers back then i don't know if offices nowadays maybe they could imagine like fancy startups with that as well yeah there's t

he googles of the world and i don't know if it's possible to take a shower in the office also they do have showers you know even bedrooms and things like that no but still like we should probably dedicate it into an entire episode like remote in person stuff like that there is a lot we are getting into that quite a bit yeah but i would say yeah in general um you know yeah just uh research is a great tool to have in your toolbox but it's it's uh you know at the same time by using research expect

to increase your tool set in your toolbox by in you know infinitely so it just brings um more solutions but also more problems uh that's that's what i would still yeah but it's necessary regardless like you are going to see more problems but that's fine that's fine and that comes with the territory i would say so okay yesterday we saw a presentation about rfcs so we didn't really get into those so do you have some because sometimes or often uh rfcs are used as a basis for implementing stuff once

they come to you know being let's say just documents that are not that alive that people don't really have many comments to live to live on and they're used as you know this a source of truth let's say do you have some experience working with rfcs and implementing stuff based on them i would first start with the rfcs because i think it's really important to start with um so yesterday was uh bjs december 2023 probably the last one for this year and i would also say kudos to stojan for a very gre

at presentation he he did talk in depth about rfcs and uh how they use those at um super base the company he's working for um so just setting the context and um i you know obviously uh there are different ways to use rfcs and um rfcs can be used um and i think at the same time actually they are a very good research tool yeah uh but with the pre-requisite that you already did some research yourself uh you're coming with this unfinished idea and you're presenting it to other people so that you kno

w you can get their comments or like what stojan said i really like that a request for thoughts not comments because comments are like you know can be grammar thing yeah or you know like very superficial right but the most important thing in my opinion is getting thoughts um from other developers uh based on your research findings so you have a set of uh research findings that you and you have a goal that you want to achieve so you know this is you uh basically can be considered as an as an rfc

i i wouldn't get too deep into what rfc is or could be but i we can maybe maybe work on that definition and at automatic we do use rfcs a lot uh had had uh the experience of uh using them and they are basically uh being used uh exactly the way as i described the definition so you know um people would would come with like uh almost fully baked ideas and which is ready to present in in front of uh other people and yeah just basically here is what i have just you know give me your thoughts um so i

would also make the comparison with uh the company that you and i worked on in and we use no rfcs no documentation at all but the thing is there was no need for that because things so bad you know all the research happened in person um either when we had lunch together or coffee break or beer break or whatever and you know we just like through the dialogue uh we just um built the rfc in our minds up to the point where sometimes we would collectively uh hallucinate which is very interesting yeah

it did happen but you know working remotely especially at automatic uh this mode of working is not possible so uh we use rfcs a lot and they are they have to have uh in order for you to get some receive some comments or thoughts from people you actually have to present your findings and uh so that other can build others can build on top of that yeah whereas uh you know you cannot really just start with hey what if we built a peer-to-peer network in our so you know you don't start an rfc like i m

ean you could start it like that with within your head and then just like theory but um in you know uh in working remotely you just have to like really um understand and clarity uh put some clarity into the idea yourself first before sharing it with others um but uh definitely a really good research tool i would not say the you know there are um obviously it's part of documentation can be used as a documentation um uh but uh definitely requires um a lot of depending on the rfc of course there ar

e different levels of rfc but definitely requires some amount of research uh before being able to and uh you know for as for the process for writing rfc i think we might have a whole different episode about that which is yeah uh you know you should probably invite stojan over for that one yeah but uh you know technical writing content writing content generation in general i think is a whole different topic and that covers very interesting bits like how do you engage the audience yeah it's a whol

e different rabbit hole like right deserves not probably more than one episode unto itself so so would prefer not to get too deep into that but very interesting topic and i would say even though research is a prerequisite um uh actually to write a really good rfc um takes more than just research yeah yeah for sure um and probably you can leave it at that unless you have something more to add to the rfc no not really i don't really have a lot of experience writing them i did write some for some p

roposals but i've had some great experiences implementing stuff based on rfc's for example the toss uploader tus which there is some effort currently to actually make it a part of some some web standard and probably for 10 years that's been no it's no no actually it's it's pretty new like it's been a thing that's been used in some companies and stuff there's a whole lot of implementations for various servers but last year or something like that i don't know i don't know i don't know i don't know

i don't know i don't know i don't know i don't know i don't know i don't know i don't know i don't know about that there was uh this effort to actually make it a part of some web standard can you remind me was this the thing about uh resumable downloads yeah uploads resumable uploads exactly yes that was it and it's it was beautiful in that it was a very simple document you know there were like shoots and musts about that that mapped really uh neatly to http requests and that in turn mapped to

how you can translate those on a client and the server and this was back in like 2015 something like that and you know we still had to fight internet explorer back then and this thing was sort of a breath of fresh air for me personally because i got to implement something that just made sense was simple and i didn't didn't have to fight a bunch of browsers and browser standards for it to work so yeah i would like to just you know kudos to us you guys did a great job and i think this is a great e

xample you know that rfcs can indeed be used differently um obviously you know one one thing is the documentation aspect the the other one is could it be used as a design document uh is it really just like research results and i think you will find you will not find it as a design document but it will be used as a design document but it will be used as a design document and i think you will find it as a design document a single definition for what rfc is but i can make a comparison for with php

source so this php core and how they use rfc they basically use rfcs to so they have like this voting mechanism which i believe was two-thirds so in my opinion and my experience as far as i saw the the way php core uses rfcs is just make a decision about a particular uh you know design either addition or change or deletion and um then you know comes the voting process rfc accepted or rejected and that's it this is where the rfc uh you know but uh the interesting bit is that you won't find this r

fc referenced in any of the docs as far as i saw maybe i'm wrong about this but i never had i have i seen uh any references to rfc to php rfcs in the php docs right documentation so you know they use it just as a way to make a decision and the way you described it is really you know interesting and i will also say uh important because if an rfc gives you um you know just what you need to design a system or a part of a system or a part of a system you know along with uh research results and thing

s like that and like what you the experience you had with us if you can just like really look at our an rfc and be able to go back and implement it i think that's a great example for a very well written rfc yeah yeah i had the chance to uh work with a co-worker on who is basically building an html parser in wordpress and i'm not sure if that's the right word for it but i'm not sure if that's the right word for it but i'm not sure if that's the right word for it but i'm not sure if that's the rig

ht word for it and uh you know the html specifications are very vague i don't remember the exact details but it was something something with inner and outer html and the rfc standards for this basically have a hole like a literal gap that is undefined and you see different behavior in safari or in firefox and you know i obviously there is probably a good reason why this was written that way because it's probably a complex problem but um this is where you know it becomes much trickier to navigate

where um like i said don't remember the exact details but i think it had something to do with um escaping out of the html uh fragment by either using inner or outer html and so this worked in chrome or you were not able to escape out of it but it you could do it in safari and if you go to the rfc there is a gap so unlike thus uh you know what what do you do in cases like this it's really up on up uh to the designers of the system to make a decision and this is why we have tons of browsers with

different behaviors nowadays cases and stuff but yeah an rfc is a tool ultimately and as a tool it can be used in imperfectly or wrongly so you know it's a tool yeah that's the bottom line for sure i definitely agree and i'm not saying that all rfcs should literally have zero gaps but the biggest disadvantage the biggest trade-off of using rfc as a design document is uh unless it's thus or some proper the good examples uh you will probably arrive to the point where you're you have to say or you

you find yourself where this is not documented i have to make this decision myself and the burden comes on you yeah essentially cool so i think that's we covered it or do we have something more to say on this topic maybe something about spreading research culture how do we make it make that more a part of you know everyday developers lives because i feel they're is a distinct lack of it especially around here like most of what i'm seeing especially in you know service-oriented companies is that

they just turn solutions they don't take too much time to you know understand and provide additional value and i mean i get the business part sure but you have to invest in quality as well and you have to invest in your developers toolboxes as well in order for them to become better and in turn produce better stuff so i would i think it's a great question and uh there are two distinctions to be made uh first is the distinction like what is the intended outcome so if you were if somebody came her

e in this room and asked me and you what are you guys doing well we are basically doing this thing well and you know obviously the most common next question would be does it bring any money so we would say no for sure uh until at least until now uh so there that's one distinction and the other distinction is you know when you're in a company obviously you are trying to convince ceo cto uh why they should start doing research i guess the first question would be you know does it bring any money wh

at's the value what's right um so to me the way i see it first uh research is a very natural progression uh you cannot force somebody to do research but you can show them the beauty of the of you know what what research um gets you or can get you and so it has you know at some point it has to come from the person doing the research even if you were able to convince the cto that they should include research in their processes or whatever if the people within the organization are not um curious en

ough to dig deeper and understand different solutions um you know yeah you will have convinced the cto but uh then you have to convince the other yeah probably it has to do with culture and it has to do with the person that you're trying to convince you're probably not going to be able to convince everybody that hey that's probably fine because you know not everybody would be convinced that this is a great tool to use right some people would be fine without it right and uh it's a great question

i mean you also mentioned agencies and agencies especially i think have this um they have this like usual cycle of war not cycle but usual pattern so if you were to take a job and you were to take a job take a random 10 agencies you will notice one pattern which which i found was uh they they found the thing that works best for them and they just uh get very uh they stick to it and i'm not saying this is necessarily bad it's it's a good thing but uh i think introducing research you know both in

the in the aspect of technologies you're using but also in the aspect of what processes is this company using or um how are they making decisions let's do some research let's figure out what are the alternatives can uh even if you think you have a very good process or even if we think we have like very good setup with this um you know um podcast here uh obviously you and i you know mostly i would say mostly you uh do research very often and experiment with things what if we put the lighting ther

e what if we put the lighting there what if we put the lighting there what if we put what if we what if you sit there and so i think they're learning so yeah and exactly so research really gives you the opportunity to learn and grow and even if you are convinced yourself that you're you know as an agency or or even a big company i don't know have like the best processes and whatever still research can give you deeper insights what things can be improved and what things should be kept so i think

it's a very in my opinion very valuable tool to um solve problems but also introduce more problems yeah but but sure it's it's this thing that inspires progress so like it makes you leave a comfort zone it makes you try to see a problem from from multiple angles and personally i think there's a lot of value in that like you create better professionals that way you create better seniors and better leaders that way so you're not just you know take a junior teach them to code and they'll be code mo

nkeying like forever and ever and ever like that's not really a great idea and not really a great future for your own company like you know i could probably make a money argument here as well yes there is a certain investment in this even a monetary investment but long term that really comes back and pays back for you as a company in general so yeah and you know all of the things it's very hard to generalize because it depends on the company size on a lot of the company culture yeah yeah so uh a

nd uh but in general i would definitely agree and say that um you know if you at least if you have reached uh up until a point where you feel like you're like this starts to feel kind of boring uh maybe the best time to start focusing more on research because um and i i would also generalize this not only in the it world but in life in general when you you know get bored from particular um thing that you're doing like i don't know cooking or whatever it is drawing you can start doing some other

things like um you know i very interesting for myself i did not used to read a lot when i was younger but now i started reading more and more and i figured out that it's you know it's a great way to um to uh increase my knowledge because previously was mostly trial and error and both of those are different aspects of research but uh having researched the way i research is also interesting and i found out that this is more um optimal let's say uh you know reading books versus building all the thi

ngs yourself um so i would definitely say you know if if if at some point a company gets the feeling like this is boring or maybe not boring also but things like um how can we make it more interesting like what you said or maybe even use it as a tool to motivate people um and you know it it requires like i said it it's it requires an adventurous spirit right so it requires your or the person's curiosity to go and research um you know dungeons and whatever especially those that were not intended

to be explored yeah reverse engineering um and if it does not come from the person themselves um it could feel like something that you know you are forcing people to do now the bigger question is how do you sell this or how do you show the beauty of this which i have not found the answer to yet um but i would be very interested to to find out that one hopefully by doing more research no for real i don't really have like anything to add to that it's sort of you know it's very mysterious to me as

well it's i just don't have anything smart to say there uh it's uh you know it's uh yeah uh the uh we we were we're basically jumping into the philosophical realm but um and uh at the same time even if i had the chance to even if i had the tool to convince somebody to who was not who did not want to do research but uh and i could change their minds right away i don't think i'm going to change their minds right away i don't think i'm going to change their minds right away it's a great tool to hav

e because i would prefer if it came from themselves otherwise it would still feel like something that i uh literally micromanaged in a way so a proper research has you know has to be done with let's say let me put it in the most cliche way uh proper research has to be done with love so i will i will the secret ingredient is love um so yeah curiosity all of those bits i think you know if you don't have the love for the thing you are interested in how that works you you really want to dissect it t

hen um maybe not there yet maybe just continue doing what you're doing and when you feel it is a need um you know it's also important to to figure out what what is it that people enjoy doing so you know if uh so you and i share a lot of biases this is why conversations are most easy you know they go very easy between us but if you were to introduce a junior here right now or even a more senior person than us either extreme doesn't matter um how do you convince a junior that research is a good to

ol unless they themselves felt that maybe we should try it as an experiment see what happens i don't know no but you know when i was a junior myself i just literally felt like felt really good when i just wrote something compiled and executed yeah this is the feeling i was chasing and so if this junior imaginary junior sits between us and who is a person that chases the feeling of compile run works and they're just not there yet or even a more senior person who probably some wizard kind of perso

n that would come come here to us and say you know you shouldn't you should not do research probably came up full circle um so yeah it's i think i think it's a it's a it's a it's a it's a it's a it's basically you know it's important for people to align to align themselves and make sure they are sharing the journey yeah so i would say introduce research at the point you feel like should be introduced all right cool so maybe that's an interesting closer because like we've been at this for quite a

while now so okay sort of to wrap this up we've done books twice let's do games now what are you currently playing i i have pre-ordered um zelda what was it uh tears of the kingdom a long time ago but i was so busy during the past period and i'm really hoping now during the holidays to spend some time playing with it um but short answer is nothing really maybe just a quick chess game here and there but nothing too serious mostly because of lack of time right right right and yourself well i'm tr

ying to have you know i'm sort of like at the end of the first chapter of balder's gate 3 and i'm trying to invest more time in it but it's sort of a struggle i usually end up on the couch with netflix and similar stuff sometimes even books when i have the energy for that but yeah i'm trying to play balder's gate and i'm sort of doing some dnd games as well so i'm pretty happy with you know general my general gaming life so that's so balder's gate is uh is an rpg right yes okay this speaks to th

e shared biases that you and i have but i can probably leave it at there oh yeah i'm pretty deep into like anything dnd and rpg i'm very like probably my most my longest running hobby or i'm not sure if i even get to call it a hobby anymore it's sort of more than that but i i don't want to you know probably we can discuss this indefinitely but just one last question what what is it that you feel like draws you to this kind of games because i have the same feeling and i think there is a very inte

resting research aspect to it the endless complexity the endless complexity and the but there's a like sort of a caveat to that the endless complexity that allows you to get infinitely creative and like you can tell stories you can collaboratively tell stories you can do a bunch of interesting things in a way that wouldn't really translate to the real world well you know you can play a werewolf for god's sake you know like you can do stuff like that it's it's weird it's creative it's you know a

workout for your creative brain and okay i like that it presses a lot of yes it presses a lot of buttons for me personally and i'm not sure whether i can put it in a couple of sentences it'll probably require yeah a bunch of time so yeah uh definitely agree on the mental gymnastics part and um i think we are going back in circles now yeah where i mentioned the previous previously the quote men have a special way of complicating things we do but i don't think it's a good thing to do it's not a go

od thing to do it's not a good thing to do it's not a good thing to do it's not a good thing to do it's not a good thing to do maybe a topic for a different session is complexity required for um creativity that's a very it's a deep question so yeah we will discuss it i'm going to write that one down and it's going to be an episode at some point we have a bunch of those so we're not going anywhere so with that i guess we can close this one so this has been boro thank you for being with us in this

method of corner episode see you next time thank you bye