#136 Dotan Nahum on building your own toolbox

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Dotan Nahum 0:00
To be able to effectively learn, you need to put your brain in alert mode, and your brain goes there, when naturally, you don't understand something. So you know, you build frustration, and your brain is kind of going into a dead end and trying to recover. And then this is the moment where your brain is primed to learn. So if you're not stressing out, and you're not putting yourself in a situation where your brain tells you, you know, danger, and I don't understand, if you're not doing that, then your learning will be less effective.

Tim Bourguignon 0:47
Hello, and welcome to developer's journey, podcast, bringing you the making of stories of successful software developers to help you on your upcoming journey. My name is Tim Bourguignon. And on this episode 136, I received Dotan Nahum. Dotan is the founder and CEO of spectral, a developer-first cybersecurity company. He's an experienced developer himself and open source committer since 1999. And he is very active in promoting engineering culture in Israel. He's finally a full time author and a fellow podcast host. Dotan, welcome to DevJourney.

Dotan Nahum 1:21
Hey, how are you?

Tim Bourguignon 1:22
Pretty good, pretty good, really cool to to have you on. So Dotan, the show exists to help the listeners understand what your story look like, and imagine how to shape their own future. So, as always, let's go back to your beginning. Where would you place the start of your developer's journey?

Dotan Nahum 1:39
Yep. So. So it's always a hard question to know where to start? I think I think I'll start with what jumps into my head, which is kind of fairly, very early on, I think I was around 14, maybe that that is around 95. And I think the general theme back then was hardship and scarcity. So you know, I didn't have the proper tech, I didn't have a proper computer, I barely had books to learn how to code. And I barely had anyone I knew that could help me learn, basically, the internet was, was kind of a baby internet, right? There wasn't any, any Stack Overflow, or, you know, any Google back then at all. And I had this clunky, I think 14 k modem. So that would be, I think it was 14 k bits. So you would basically download in a few, I don't know, one kilobyte per second, if you ever found an internet connection. And on top of all of that, I was stuck in the kind of suburb, not in a main city. So I didn't even have a proper library. To get books, it was basically me, my, what I would call a computer. It was maybe I think it 286 386 something very old and very outdated. And the programs I had, and the big channel channels was how to get knowledge, you know, to basically spend my time in a better way. So yeah, so that led me basically into some hacking activities. So that's how I started. Basically, the goal was to gain knowledge. And by that to find Internet, and by that to find, you know, some accounts, there wasn't, by the way, it wasn't any kind of official internet in a country that you could buy. So even if you had money, you couldn't get internet. So I kind of weaseled my way into an internet account in the university. So that was my first way, my first step into gaining knowledge. And then I downloaded some hacking manuals, and you know, all that kind of sort of things. And before before I knew it, I was actually writing code in order to get knowledge. So, you know, learning more and more and in a, in a, in a scenario when where, you know, it's not available the knowledge. So that I think that that is my, my first memory in my first step into, you know, being more curious and exploring more, I think, than the normal. So, or basically when you don't have something or you develop this, you know, urge to actually get it that is it stayed stays with you, I think for a long time. So this passion of of knowing, and curiosity and knowledge when basically you're born into a situation where you can't get it, it's not available. That is I think that is what defined, you know, if we take it to 95 and today, it's really long time after that. I think this is this what define my By ambition to always learn to keep learning,

Tim Bourguignon 5:03
Do you think you would have been attracted to something else? If the scarcity had been towards some something else entirely? I don't know. If you couldn't get any information about football, then you would have tried to search just because it bugs you not to have any information and be passionate about football? Or were you interested? especially about computers? Because? Because there was something else behind it?

Dotan Nahum 5:28
Yeah, I think it's a good question. Because I think the answer is, it's kind of a nice combination, where we're, I think computers, and maybe we can call it information technology, and, you know, the Information Age created this world, virtual world where where you can learn anything, and you need to go at least in 95, for me, I needed to bust a few doors in order to get to this world where knowledge is, you know, is, is beyond what I can, I can imagine, back then I had like two books in my, my room and getting books was very hard. And, you know, there was a world of knowledge waiting for me. And I had to, you know, that was the feeling I had to do everything I can to get to it, because, you know, I wanted to learn. And basically, all the rest of the temptation of a young kid weren't there. I mean, I was living in a kind of crappy neighborhood, you know, if I, even if I weren't, you know, went out, there wasn't anything interesting to do. So basically, I was stuck in the room with, with a computer and, and now I was asking myself, what's, you know, what, what do I need to do in order to get you know, to get past this, I think there are technical and technological obstacles. So I learned how to hack I learned low level TCP IP, I learned weaknesses of systems, I learned how to reverse engineer, so basically, opening up binaries, and, you know, downloading tools and trying to find my way into more knowledge. So, and back then that was kind of, you know, everything you saw in movies, you know, hackers and Kevin Mitnick and all these personas, which I admired. back then. So yeah, that that was the way I started. And basically, after I think, around 9899, I realized that actually, there's a whole other world that you can, you know, use the same knowledge of reverse engineering and building software, I was basically building software in assembly and C, and that software was brought forcers, and, you know, all the, all the tool chain of your standard hacker, so I discovered that there's a whole new world that I can, I can play with, you know, enter this world of, of building, you know, building software, and that was open source. So, around 9899, I discovered there's this thing called Linux, I downloaded it, it took a month to download it. And it took around two weeks to actually build and configure and, you know, basically, you know, break my head against figuring out how do I take my hardware, whatever, you know, sound card was there, just to remind, and to get back into the area, there was so many copies of, you know, standard sound cards that, you know, drivers for very, very hard to get, and to support, you know, to support all the hardware was so such a hard task, because, you know, there are so many knockoffs and nothing, nothing really worked with nothing. So you take Linux and basically that was up to your luck to see if you got if your knockoff soundcard. And video card actually worked. So that was the era no compatibility, nothing was plug and play. Yeah, so it was a month of downloading Linux, and then onto floppies and then reassembling it and installing it and trying to figure out how the kernel works and how to actually make it work that took another week or two, if you ever, ever were successful. Yeah. So basically, I, I submerge myself in this world and started building software. And the first thing I needed I knew how to build was, you know, if, if previously I was building offensive tools, now I was thinking about let's build defensive tools. So I built my first I think my first open source project was intrusion detection system, which was basically an agent that lives in one of those very early very, very immature systems. You know, it was slackware, whatever version there was back then, and an agent that basically lived on the on the OS and figured out if anyone has hacked into the system or changed files, and so on. By the way, I later later learned that I was doing this around 9899 that in the bubble area of 2000, all the you know, all the exits, I learned there was a couple companies doing this commercially, and selling this product, this kind of products to to other companies. But, but back then I was basically just a kid trying to pass time. So, in real life, there isn't any commercial success doing what I what I was doing. So yeah, so that that was how I started. That gave me kind of knowledge, deep knowledge into how an operating system works. And you know, how the canal works, whatever canal it was, it was, sometimes it was windows, because I learned how to hack the systems. And sometimes it was Linux because I wanted to know how to properly install and configure Linux. So I had to do these times you had to learn how the kernel works and how to how the driver works. And you know, worth Where are the bytes misaligned. So he can actually make it all work. And yeah, so. So eventually, I ended up with, I think, more than average knowledge of assembly and CPU architecture, and C, and Perl and all these, I think, popular languages that was back in the day. That was how I how I started, I think.

Tim Bourguignon 11:25
And this is this is still pre college. It's still high school time. Oh, yeah. Oh, yeah. Yeah, that's, that was high school time. Wow. And yeah, I think through that, I think through that, I was basically, when I was doing some hacking and all these kind of things I, I connected up with other people, you know, over IRC, that was also kind of initial stages. Before I say, there was BBs and BBs were very local to your town. And, and now you could actually connect mostly to Europe. And talk to other people with the same passion, with the same I think, sociological a situation where, you know, I was living in a fairly deserted town, and not a lot of resources to use. So we were grouping up and discussing technology. And I think, you know, in many ways, like, like you, like we actually experienced right now with slack and communities, and you know, discord, and all these things. So we're doing it back in 9697. talking over IRC, we had everything that you have now in slack. So we had bots, and we have, we have automation. And we have tooling that he each member of the of the group built, and we had competition. So there was there were people who are actually better than others in terms of, you know, hacking and, and creating and trying to defeat, we were trying to defeat encryption algorithms in many various ways. There was a whole culture of competition around it. And also, I think, in Europe, there was a nice, great, I think, and also mostly in Germany, great culture of, of the demo scene, which also kind of interfaced with this world. So people were running, nice competitions to create, again, this is back in 97. Around that time, competitions to create, you know, visualizations in eight kilobytes, unity create this 3d demo, which is crazy, crazy, procedurally generated, and there was so many competitions in art and computer generated art, and all these things were actually being done, kind of in the underground scene. And I was part of this whole thing, which also allowed me in very early stages to connect with other, you know, cultures and to experience diversity and to see how other programmers think with which was very, you know, mind opening, especially when you're, when you're in high school time, and basically, you know, the world isn't connected yet. So you don't actually know anyone from other countries, unless you've actually mail them there wasn't there barely was email, at least for us. So yeah, so that was a, that was a pretty good experience, it left a very deep impression. One question that comes to mind is that when when you are so young and already so versed into computer, tech and hacking in this case, how do you dread the danger of starting to do something you shouldn't be doing? Most of the time, you're just this curious kid who wants to learn that that it was that was my my thing. So I was, you know, gulping, any kind of information I could. So I I was reading about encryption algorithms. That information was public. Basically, there was this big, dramatic competition who will be the next encryption standard for, for the American government. So there was a fight between various academic groups, and each academic group proposed their own encryption algorithm, and event, eventually, there was one, one winner, and I was following this, like a, you know, like a TV series for me. So I was downloading all the papers, and kind of with my high school math, printing them and trying to follow word by word, and, you know, trying to implement them in assembly and trying to find the weaknesses, just like other any other researcher. So, in that, in that sense, there wasn't any, you know, direct feeling of something wrong. There was just, you know, trying to participate in this. I don't know, it wasn't, it was above my class, right, I was reading academic papers that people worked on for years. But at least I tried and whatever I got successful with, I kind of build tools to actually automate and you know, have a given, if I found a weakness, then let's try and find something that uses this encryption, and try to actually beat it. So that that was, that was most of the activity, the real research activity. But yeah, you know, and for fun, you know, you had games, so sometimes you wanted to cheat in games. So, basically, you would actually find the places in memory, the games stores, the, the, you know, the score, and how it saves and analyze the format that, you know, the safe game format, and, you know, and basically cheat, that all requires a certain level of, of, you know, nice understanding of reverse engineering, I remember that fondly. I think that was Fallout 2, I think that I hacked my way around, and just to get everything I could, I wanted and so that's, that's the one I really researched extensively in HEX and, and try to modify every variables and see what that does.

Dotan Nahum 17:05
Yep. And I think the world the world today is very different. Because what you want to get you can get, I mean, if you want to download games, it's, you know, the cost of a game is so minimal. You know, it's basically the distribution model is so great, that you can buy anything you want. And, and back then it wasn't the reality, the distribution model was so hard that even if you had the money, you couldn't get anything, you know. So yeah, it was, that was a period of time that I don't think exists today.

Tim Bourguignon 17:42
That's true. That's true.

Dotan Nahum 17:43
Yeah, but but but for me, it left an impression. And then then like any, any Israeli, I think, citizen, you go into the army, the army kind of got everything for four years. And I was responsible for a few classified system is mostly electronics and radio, and there are experienced crazy responsibility of maintaining a system with a complexity of, I don't know, an airplane. And yeah, very, again, the same story very hard. I mean, very little help. And you need to become, you need to quickly, you know, you've been thrown into this deep pool, and you need to quickly learn how to swim, basically. So yeah, so that that kind of shaped my way to debug things. When you're, you know, you're, you're facing a difficult situation, in terms of, I don't know how to call it like warfare, and then you need to fix the system, or someone dies, I guess, if we can take it to that kind of extreme. And the system is so complex, it's insane. The level of complexity, and you actually need to devise ways to you know, optimize how you work and how you actually can fix things to your friends can can keep their day as usual, and you know, not have a nasty surprise. So that was four years of that thing. And then just jumping ahead, I hit University. That's, that's usually what you do around here after after the army. And yeah, for me, university was a way to relax and to delve into other areas of again, around programming. So I learned distributed systems and, you know, parallelism and cryptography. So like Finally, I kind of learned what i what i was reading. I learned the theory behind it properly. And all these deeper things that I really wanted to learn but didn't have the chance. And yeah, and that that kind of closes My, my, I guess, ramp up towards doing this profession.

Tim Bourguignon 20:01
Were you always sure that you would become not necessarily a software developer, but a software professional?

Dotan Nahum 20:07
No, I think I, what I did during my high school era was to play around in trying to prove that I can beat a lot of systems. And I was completely sure I was going to be a fighter pilot. I was on my way through that. So I passed a lot of the stages by that, but then I dropped in Yeah, and when I dropped, I figured, okay, so let's do the second best thing they want to do, which is programming. So it was my second choice again.

Tim Bourguignon 20:40
Okay. And when did you did you decide on which path to take, you could have gone in many directions you could have remained in in hacking, you could have gone the software development way you could go into cybersecurity, which you did. But when was your this path or this fork ahead of you? And how did you decide on which path to take?

Dotan Nahum 20:59
Oh, yeah, so so I think this was around 2005, a little bit after my, after I get released from the army. And in parallel to my university work, I was also, you know, doing my open source work. And fairly shortly after building my first startup, and I think, around 2005, I don't remember why there was this wave of software craftsmanship, and extreme programming, and all these, all these things were kind of fresh, and I was kind of hitting a level of frustration, because I wanted to be to code faster, and better and more to be more precise. And then I figured I kind of analyzed how I progressed with time. And I figured, if I don't do something that often in an aware way, something that is very definite with how I manage myself, I probably won't progress any any further. So I was stuck, you know, in a level where I was fairly good at C, and Perl and Python. But I wanted to do more, I wanted to understand everything, without really an idea what it is to be able to understand everything I wanted to build software correctly. I didn't know how to do that. So what I did is I actually sat down and plan my five years ahead, back in 2005, that was kind of planning, it will, it felt like I'm planning 30 years in the future. It was so young. And you know, at this stage, no one plans, you know, you just want to have fun. So I was planning that. And I figured I need some metric to measure myself. And I decided, you know, I agreed with myself and made a promise to actually improve. And basically, once I've done that, I kind of went into a, you know, crazy mode when I tried to learn more. So I, I remember, I picked up a functional programming, that was a weird thing for me, I was coming from assembly from C, low level stuff. And suddenly, I was experiencing this thing called functional programming. So I started with Lisp and scheme. And later, Microsoft stack F sharp. And this whole thing was super bizarre, to me, but I decided this is I need to complete this and to understand this no matter what, because I believe that it will bring me forward, you know, in my understanding of software, and so on and so forth. So having a goal really helped, you know, overcoming what I felt was, you know, I don't want to learn this, because it looks bizarre, it looks strange. But I later, you know, after, after, actually after, after you learn functional programming, you realize that, that Yeah, there are two sides to the world as to, you know, the imperative one, the functional one. And actually, to get better, you need to understand both. So that was the aha moment. And shortly after that, I was pretty sure that this is the way to move forward. So I was planning my way year by year, my goals, and yeah, I discovered it, I have something for languages, I could learn them pretty fast, and be proficient with them to high level pretty quickly, because I would what I was doing is I was kind of doing the same thing when it was hacking. So first, I used to actually go deep into the water right off the bat. So if I was if I was picking up F sharp, I would you know, start a project with it, you know, without thinking or overanalyzing it, I would hit a brick wall and then understand what what do I don't understand and then go and learn learn the basics and learn everything and you know later there was this I think movement of learn things the hard way.

Tim Bourguignon 24:43
There were many books on "learn things the hard way".

Dotan Nahum 24:46
Yep, so it was some person from the Ruby community that solid this and he figured I think it was c that he was trying to learn so we did learn C the hard way and then immediately Every one discovered this. So and also later, I learned that this is a good way I started going to how to learn things like this is much later. But I figured, and I read about the name of the book, but there was a good idea there. And a thesis where to be able to effectively learn, you need to put your brain in alert mode, and your brain goes there, when naturally, you don't understand something. So you know, you build frustration, and your brain is kind of going into a dead end and trying to recover. And then this is the moment where your brain is trying to learn. So if you're not stressing out, and you're not putting yourself in a situation where your brain tells you, you know, danger, and I don't understand, if you're not doing that, then your learning will be less effective. So just, you know, listening, just as a human that that's what we do so, or let's take it the other way. If you're, if you're figuring, okay, so let's learn, I don't know, a scholar from a book. And, you know, you pick up a nice hot mug off of coffee, and then you sit on a chair and start reading the book. I guess most of the material will be nice to read, but not really actionable. So you'll close the book and go figure Okay, I read the book, I can code scholar,

Tim Bourguignon 26:21
you probably won't, won't be very successful. So So know, Neo-style learning in the matrix "I know kung-fu now", just because I got plugged in the machine for for 15 minutes.

Dotan Nahum 26:32
Yeah. And, you know, and that's what I was doing intuitively, because that's what what I knew from my early stages and in life, and it worked really well. I mean, I picked up so many languages, that I soon started to see patterns between things. So I was, I think this was already 2008, when dotnet was starting to to be a really great platform. And I was playing with so many technologies that I could actually find the right tool for the problem, which saved me so many, so many headaches.

Tim Bourguignon 27:07
I have one question about languages. I think that's a Reuven Learner who said this on

the show:
"at some point, you realize you're writing Python with a C sharp accent". And if you if you learn so many languages, how do you make sure that at some point, you are idiomatic about the language. That you're really using the language how it was intended to be used, and on not with the strong accent of another language, if we compare spoken languages and programming languages.

Dotan Nahum 27:41
That was really a challenge for me. I met Reuven, by the way. And I think he worked. He kind of put the session in my one of my companies that was working, okay. Okay. But yeah, initially, I used you'll, you'll laugh, but I use syntax coloring, so I had different color for different languages. That's how I, you know, programmed my brain to kind of enter into C sharp mode and Python mode, and so on, and so forth. And a really, this was really a, you know, kind of a fear. For me, I was dreading the moment where I would write a Python esque code in Perl or Java. Today, I was, you know, I was really dreading the moment where I'll get mixed with everything and lose everything. So I want to be great at all of the languages in the same time. So I was using syntax scholars, different programming languages had different syntax colors, so different themes. But it tooks it took quite a few years, actually, to move to a stage where I didn't care. I mean, to use the single color I would, my brain was fine. I move between languages, like freely, and I know exactly what kind of idiom to use, in which languages. And for that, I actually figured I need to learn functional programming really well. And if I do that, I can actually jump between languages without worrying too much. So and that's what I did. So in Python, modern Python, I use tools, which is a nice functional programming library. And basically, I can express myself really, really well. Most algorithms, most code, I can write functionally, in any language, with a proper supporting infrastructure. And that's how I can you know, jump between languages and, and basically, the code is, is great, because it's really understandable because it's functional, it has no side effects. So I have that also is a nice, you know, extra. But yeah, it is complex to devise a way to jump between languages and be super efficient in any language that you'd like it is it is needed.

Tim Bourguignon 29:50
So if I go to I got you correctly, you kind of found the way that functional is something that works on many languages, and that's kind of some kind of pattern that allows you to write very efficient and elegant code, regardless of the language. And then you can flavor it, depending on which language you're using. But as long as you're using true functional code, then you're, you're fine. And you know, you're gonna write good code for the language you're using.

Dotan Nahum 30:16
You got it right. And also, it's a mix, right? Because, at least in my, during my years learning, and it's always a learning experience. Even today, I learned domain driven design, really early on, I mean, I was working with, with a company that actually adopted it at scale really early, I think this was 2006, maybe. So the only book was, you know, the classical, pale blue book, that you could learn domain driven design form, and everything was pretty fresh and an initial, so you didn't have any blog posts or anything like that, you combine the thinking of domain driven design, you combine the expressiveness and, and clarity of functional programming. And, you know, you learn about type systems and compilers and how they work. And then you realize that you can actually gain a lot of knowledge from understanding how types work and you can actually figure out which type system is better than the other, and how to use it to your benefit. And when you combine everything, then you have, I don't know how to call it you have Zen and you have the epiphany of you know, programming is nothing, you know, you pass the stage of you can program anything you want and design it in a very clear way. And now you have different kind of gaps and different kind of obstacles. So yeah, so I think basically, I would divide it to, I think at the start, you have this mindset gap, where you you want to realize, you know, he realized that you want to be a programmer, and there's something very, there is a Mystique around it, right. So for me it was you can create without material, or you don't need to buy anything you can create from scratch, anything you can dream up. So that was the mistake for me. And then you have the language gap, right, you need to kind of figure out this this awkward language called C or Berto whatever you may have, and you need to learn it. And very initially, it's not easy to learn, right? For any any any human being like any other language actually, even spoken language. So we need to go and bridge that gap. Sometimes this is a hard thing to do. Because your first language means you need to learn everything in your what is a follow what is an if statement. And then there is the knowledge gap, which is you know, you have a language. Now, you need to figure out how do you bridge knowledge? So, okay, so go program, this billing service, what's a billing service? And what's the transaction? Now, how do I actually go into this domain efficiently? How do I learn what the banker knows, know in order to actually model a banking process, for example. And, and by the way, for me, there was also a mechanical gap, I kind of realized that I, I can learn quickly, I devised my ways to learn quickly, but I can type as fast as I want. So this was a period of time where I basically bought so many keyboards, because I thought the answer is the right keyboard. That was wrong. But I did become keyboard aficionado. So I started buying all these mechanical keyboards and all these crazy keyboards to be able to type faster, any and obviously, I realized I was typing wrong, you know, from the basic and there is a theory for how to type quickly and efficiently. And also I was using my mouse and you know, pointing click. But yeah, I realized I want to relearn how to type to touch type properly. And I also tried draw rock and all these layouts just to you know, break through this, grab this, this gap. And I moved to him. And and basically, this is the best thing I did to move to vim. I think this is a tool that I wish I learned much earlier. And I think this is a tool and a mindset for how to edit and type that can follow you for your entire career and have 2030 years in the future. And today everything I do is you know is modal is fame like I use my browser. In the same way I use my editor in the same way my terminal in the same way everything is through the keyboard. I almost don't touch the mouse and if I have to touch the mouse or trackpad, I get annoyed. I did and that actually, that was a meteoric jump for me. And then the after you do that, so basically you can you're in the mindset, you can The standard language is nothing for you, you can move between languages, you can actually learn quickly anything you want. But then I discovered I need to understand failures in a better way. So then I went into a world of philosophy. So I started reading some classical philosophy, and, and go into research for understanding human failure. So there's fairly good content these days also, and books for understanding human failure, and biases, and how we make decisions. You know, there's so many biases, and so many fallacies that humans have that are programmed in our brain that are misleading. So I had this nice phase, where I started to learn more and more, and I devised my ways of understanding some thumb rules. You know, if you take Murphy's Law, that it's not just a joke, it's an actual thing. And, and, you know, when you're about to launch software, so you do a pre mortem, as well as postmortem, to understand what happened, how you can actually, you know, stop a failure, and understand the root cause and do a five why's and, you know, become a learning organization, as well as a learning person. And yeah, so. So basically, that that's how I divided You know, my progression throughout the last, I think, 20-25 years,

Tim Bourguignon 36:28
This is this is completely deliberate, which is amazing. You really set yourself to "Okay, I want to do this, and I wanted to do that". And you said you you make some some yearly goals or plans? And really, this is where I want to go. And and let's do that.

Dotan Nahum 36:45
Yeah, I think when you when you say it, it sounds easy. It's really hard. I think maybe we can talk about the sacrifices part. So I can say, it's not for, you know, some people should in take it a little bit easier. Because I'm kind of total person. But yeah, I mean, I sacrificed so much to get to a level where I really, I'm really happy with the skill set level that I have, that is weekends, you know, nights coding and weekend scouting and, and disappointments and everything you can imagine. But eventually, when, you know, I think it was worth it. Because today I can, I'm so I'm so happy coding in my you know, I'm so happy with my level of whatever I produce. You know, I sit down and I think Okay, so, yeah, there's so many edge cases is I covered and I know exactly how this is going to fail, if this is going to fail. If there will be anything in any error in production, I know exactly how it's going to fail and know how to debug and trace it. And you know, it's, it's kind of a Zen thing, when you're really, really happy with what you've produced, it's actually really worth it. And the extra is that during this whole time, I was able to, you know, mentor and and, and take people under my wing and create all these future CTOs. That actually people that worked with me and became CTOs of their company. And because I was able to give them this way of thinking and how to break up problems and how to learn quickly, and how to learn effectively. And I should also also wrote a book about this called effective work, in which I try to give all the steps that I was, you know, giving to people, you know, just in the cafeteria talk, try to write it into a book that involves How can you actually work in a better and effective way? And how can you learn in an effective way, the book is free, by the way, just decided, because of the COVID situation, I can just have, you know, give it for free. I think, in terms of how I work and how I learned to program and all of that, I think I was in a race to have, I know how to call it to have perfection, or to have to reach the silver bullet. I was in a race for that. And I and then I discover there's so many things that I've learned that other people can actually enjoy, and I can help others. While you know, in my mind, I didn't have so much help. So I basically had hardship throughout the way and and I wish someone would, would have reached out and and actually taught me a thing or two that I don't have to, you know, work so hard to learn this simple thing. So that that is what drives me, you know, drives me ahead in the future.

Tim Bourguignon 39:47
If you look back, would you do it again?

Dotan Nahum 39:49
Yeah, I think Yeah, but I think also I might have tried harder in the in the fighter and the jet fighter training course.

Tim Bourguignon 39:58
Still this nagging nagging idea, oh I could have been. You can still enjoy piloting, but maybe not fighter?

Dotan Nahum 40:05
Then it's not worth it.

Tim Bourguignon 40:10
I see. Okay, we're slowly reaching the end of our time box is there was one advice that you could pick out of this out of your book, maybe effective work? Well, just one advice to to tease the appetite of the listeners, what would that be?

Dotan Nahum 40:25
Yeah, actually, I'll give the same advice that I think I had the single advice given to me about programming and was so crucial. So it takes us back to this dark moment where, you know, nothing works. And, and you try to do the best thing and everything comes out really badly. And nothing, you know, seems to be as you planned. So I think at this moment, way back in, I don't know, 2004, or five, six, I saw this person that was really a really what I what I thought what I saw was a really successful programmer, I think it was in the rails or Ruby world. And I decided in this moment to just send an email, and, you know, ask, you know, simple in a simple sentence, how did you, you know, get to what you are? I mean, how do you do it? And I get the simple reply, one line, and he says, build your own toolbox. And that that was it. To get to the next level, that was what I realized, as a programmer, you need to do the same thing that I think, you know, a woodworker, or anything any other profession does, you know, engineering profession does, you need to make sure that you have your own toolbox, create your own, for example, it can be if you, if you love to build command line apps, then you can actually have a template for for yourself for Seelye apps, and save it, you know, on the side so that you can start off really, really quickly. You can have infrastructure, you know, logging systems that you actually use always Vyas tools that enables you to, you know, to level up in your day to day. So that would be the advice I would give you focus on building and shipping software, but also build your own tools,

Tim Bourguignon 42:14
Which would be a very nice cycle back to your beginnings, where you started...

Dotan Nahum 42:19
Exactly. Building your toolbox. Yeah, it was all there. I mean, and frankly, this is what I did most of my professional career. I mean, I was CTO and chief architect in many places. And what drove me is how can I actually solve the hardest problem and the hardest? And most effective ways to solve problems? So I can enable 100 engineers, you know, different 100 engineers, 10, engineers, 50. Engineers? And what would be these problems? And how can I solve them? And that that is actually what I did most of my my career.

Tim Bourguignon 42:57
Awesome. Fascinating. Thank you very much for this story. Dotan, where would be the best place to continue this discussion with you? Or to start a discussion with you?

Dotan Nahum 43:07
Yep. So basically, I'm on Twitter. I'm @jondot, on everywhere. So that would be Twitter and GitHub. And also, it's [email protected], which is my, the company that I founded recently. Yeah, that that will be the places.

Tim Bourguignon 43:28
Okay, and anything timely or not timely that you want to plug in?

Dotan Nahum 43:31
Oh, yeah, yeah, I think most of our material I'll be publishing would be around cybersecurity. So this is the latest phase in my, in my, I guess, my own personal evolution, I'm going back to my roots. And I decided to build tools for developers, that also take care of security. So these will be a developer first cybersecurity company. And that that is the company that I founded. So I will be publishing quite a bit of articles about security, and how can we actually bridge the gap between security and developers and how, as a developer, you can actually build safer software from the point of view of software engineering, not from the point of view of, you know, security and threat modeling, and, and all these kind of cyber things. And also, as part of that, I will be I also already released, but I will be pushing it publicly, what I call the developer experience Manifesto, which is a public website in a public GitHub repo, with principles for how to create a really great developer experience for developers with whatever tools and software you're building. And there is this nice area of, you know, taking care of the experience for the developers so the developer can be happy with, with tools and practices that they adopt. So that is Another thing, the website is dx manifesto dot Dev, and you're welcome to to visit and also, you know, push some pull requests and anything you'd like.

Tim Bourguignon 45:08
And we'll add that to the show notes. Dotan, thank you very much. It's been a blast.

Dotan Nahum 45:13
Perfect.

Tim Bourguignon 45:15
And this has been another episode of developer's journey with each other next week. I hope you have enjoyed Dotan's story as much as I did. Since the recording, I haven't been able to get his advice out of

my head:
"build your own tools". This is so simple, yet many developers and technologists I admire did exactly this. There is a subtle simplicity, yet hidden might to this advice. I am in fact surprised it didn't come out in an earlier interview. Tell me what you liked about Dotan's story, and what your are taking with you on your own journey. You can reach me on twitter, I'm at @ timothep, or use the comments section on our website under the transcript of this episode. Like Dotan, be the mentor you didn't have with those around you. Help them on their journey. And if you think this podcast could help, please pass it on! The word of mouth is how we grow. But be sure to help those friends put their brains in learning mode first!