Edaqa Mortoray: What is Programming? A book and a discussion

May 02, 2019

Edaqa Mortoray, author of “What is Programming”, joins us to discuss programming, UX, security… and even a bit of politics!

• 00:01 Joshua

  Welcome to Getting Apps Done, a mostly non technical podcast with the goal of helping you deliver software because if you didn't ship it, it didn't happen.

• 00:15 Joshua

  All right, so today we have a special guest who has written the book on programming and uh, I'll let him introduce himself, but let me see if I get this right. It's Edaqa.

• 00:25 Edaqa

  Yes.

• 00:26 Joshua

  Excellent.

• 00:27 Edaqa

  Yes thank you I am Edaqa and I have been programming for about 20 years now and I've done a lot of different things, a lot of different industries and I'm excited to have my new book out, which is a sort of guide to everything you need to know about programming and sets up the course for your career and make you a better programmer. And I'm very happy to have this opportunity to talk about it and I look forward to talking to all my readers

• 00:49 Joshua

  Over 20 years. Welcome to the club.

• 00:52 Edaqa

  I, I'm, I'm a, it's sometimes feel alone at that year mark.

• 00:58 Joshua

  It is actually quite surprising. We were talking about this the other day that I find a lot of what are classed as, senior developers have only been developing software maybe four or five years.

• 01:07 Edaqa

  Yeah.

• 01:08 Joshua

  And when I tell them, well yeah, I've been professionally developing software for about 20 years a little bit over that now they just kind of look at me like, really?

• 01:18 Edaqa

  Oh I had this uh, I had this like almost, it was this awful experience. It was like a really weird, I wouldn't say awful a really experience. I was doing a presentation in Berlin for a sketch user group for the tool I was working on and this organizer when I got there and introduced myself and stuff and like he's super excited for me to be there and I'm like, oh this is great. This is great. And like his first comment to me was like, wow, I've never met some of your 20 years experience before. And I'm like, I felt so old in that moment.

• 01:50 Joshua

  Yeah.

• 01:51 Kel

  I mean the.. The reverse of that though is that I've noticed that it doesn't take a lot to be a senior engineer. Like the, the first, the cross, that barrier is only like five years or so in. And then everything after that is all the other skills and the other things that you can grow. So I guess there's some positive and that there are lots of senior engineers who didn't have to do this for 20 years.

• 02:10 Edaqa

  Yeah, I mean I think it's great and I'm, I don't think it took me 20 years to get where I am. I mean, I keep improving at things, but I don't think it took any of us really 20 years. There's always a skills that can be improved and, but I think on the coding side, I think there's a point in coding where it's just, you just pick up new libraries as you go. There's not like a strong learning curve and the soft skills slowly keep padding themselves out. You get better at them. But I mean, I don't know if there's like exponential gains made after 10, 15 years.

• 02:42 Joshua

  No.

• 02:42 Kel

  I'd almost argue I haven't gained at all after about the first ten.

• 02:47 Joshua

  Not on that side of things. And actually we just did a series with, um, we went to Twitter and found a group of, um, a community of new developers doing a hundred days of code and we got them to interview and ask questions that they would like to know before they start their careers. And that one came up quite often. Just this concept of how do you know which language to learn and how do you learn all these languages? And trying to explain to them that actually, once you get a couple under your belt, it gets much, much easier. And that learning curve isn't there anymore and it just becomes a part of daily life you're constantly just picking up new stuff, figuring it out or not figuring it out or whatever it may be and moving on. But being in that context, you.. at some stage. Just kind of forget that that was part of the fears and your daily life as a developer.

• 03:32 Edaqa

  I mean there's, I think there's different aspects to that now, and it's part of why I wrote my book is that when I started, I didn't have the wealth of Internet tech of information to help me out. But at the same time that wealth I think really confuses people. Cause if you want to learn programming now you have like a million different resources and you have a thousand different camps and do it this way, do it this way, do it this way and everybody's saying do something else. There's a million different things to do. Whereas when I started, it was like, here, just take this language just you don't have that many options. You don't have all these mobile devices. The web was still kind of in its infancy and it's like I didn't have options so I just went with it. It was a lot. You should just take something, just go with it and learn it. And that really helped focus it I think.

• 04:16 Joshua

  Yeah, I'm glad I'm not the only one. Kellen just keeps telling me that I'm getting old, but I don't remember there being that many developer communities or that many resources at the time that you know, if you want it to learn how to program in C++ you want and you bought the one C++ book and that was it. You learn from that and there might be one crazy guy ranting on the internet about how to do this sort of that and c plus plus. And I'm really grateful to that crazy guy, but it wasn't anything like it is today where you can go on Twitter and 400 people respond to you saying, well this is how you do it or try this instead.

• 04:47 Kel

  No, I just as a note, we are almost the exact same age. So I'm also, um,

• 04:52 Joshua

  I know and you've got less hair than I have, but you still accuse me of being old.

• 04:56 Kel

  But, uh, I do see that a lot, especially I, that's actually where I started to feel my age the most is when I see folks about 5, 10 years behind kind of like, oh no, no, this is the best way. And I'm like, Oh, I remember that era where I was really excited and thought there was only one way to accomplish these things. And, and now I know.. But I know I started seeing the same patterns and I'm like, Oh yeah, we've done that before. I can learn the same language again. I can learn a different language. It's similar or learn a similar framework. And, and like you said, it's all about in the end it's about who's using your software, which is why we basically started this podcast is kind of going back to the roots.

• 05:30 Edaqa

  Yeah. I think that's important. I think it's really important to gain focus of this because these technologies, they come and go and you see these trends and a lot of people are really interested in like, this is the great new thing. And I think we as, let's see, let's just say senior developers, developers, um, you can see the patterns and it's not the same excitement because you look at these frameworks and you go like, sure, I've seen most of this. I mean, it's not new. Let's go with, and you also not willing to invest like so much time in learning anymore. You're like, I'm gonna learn to do what I want with it, but it's like I'm not going to go deeper because I know in five years, yeah, you know, it might not be there anymore.

• 06:10 Joshua

  Yeah. That was another comment you made in that video about the depth over breadth and I'm not a huge fan of that because it's exactly that. What I'm learning something new, it's to solve a particular problem or to give me some capability to support something that has a goal of mine or a goal of the end user that I'm working for. And that's much more important to me than learning everything I need or could possibly know about React or Angular or Vue or whatever it may be. Because that's what it is today is probably won't be tomorrow.

• 06:42 Edaqa

  Yes, and I think that's, and things change so fast. It's like why go into that depth and I think also when people that are writing like the manuals, the API documentation, they should also think about that is that I don't actually want to see a massive list of features. I actually prefer to see I'm trying to do this, how do I do it? And

• 06:59 Joshua

  Yeah, I love learning by example.

• 07:01 Kel

  I do see a lot more opinionated frameworks. I like that. That was something I think kind of came out of the the Internet forming and people having these arguments is the idea of a really opinionated framework that has less features but it has more opinions and just kind of made some of the choices for you and I, I feel like that's kind of one of the drivers is to avoid that type of problem.

• 07:21 Edaqa

  I mean I've seen some of the opinion frameworks and I can see it going good or bad. Sometimes I see it as just one person pushing their idea and not being open, which actually makes it more closed off as opposed to just saying like, look, I just went this way, with a bunch of defaults cause it's really cool. You could change it if you want, but I just went with it. And I think there's a very sort of schism there and which approach you take. And you have to be careful of just which one you take.

• 07:47 Kel

  I just gave a talk to a bunch of new programmers about redux and my building opinionated frameworks and what the alternatives look like. Cause that's kind of a great example of it's uh, it's pretty simplistic under the hood. You know, redux is while you used in the React community and under the hood though it's, there's barely anything there. It's just a really strong opinion on how you structure your application, which you may or may not agree with.

• 08:09 Joshua

  And that can be really important. And it's not just in frameworks. In fact, I sold the concept today to somebody talking about, uh, processes with software development, whether it's agile processes, scrum or something like that, and frameworks. It's the same idea of having that opinionated view... Actually makes life a lot easier when you've got a whole lot, a bunch of people you need to get on the same page very quickly. Just having somebody else outside of that context say, "nope, this is the way to do it" is really helpful. Even if it's not quite right, it's better than everybody saying by just sitting at a table and arguing over whether this is the right way to do it or that's the right way to do it. Just somebody, please tell them everybody, this is the way we're going to do it. I don't care who does it or what it is. As long as it's good enough, then there's a lot of value in that.

• 08:53 Edaqa

  I think that's true to an extent. There's a lot of, especially at the start of a project is really like, well, where do we start from here? And so a lot of, a lot of times you just, you don't know where to start it. And a lot of the frameworks do exactly that. They just, they just here just go with this. It will get you somewhere going and it's great. You can get projects off the ground really fast. Um, I'll admit I get frustrated by them sometimes, but that's because I already know what I want to do and how I want to do it, but I'm willing to go with it as long as there's a way to sort of break it and make exceptions.

• 09:25 Joshua

  Yeah and when it comes time that you need to iterate your process and make it better. If it's hindering you from doing that, then it becomes a significant problem. But certainly, again, early days, having something opinionated gives you a starting point that's really handy at times.

• 09:40 Edaqa

  Yes, I agree with that. And I mean, I think I had, I wrote an article recently about saying I don't know how to write a website and I felt this too, is that they're lacking some of these frameworks. As I sat down and looked at like the myriad of tools I go to, like I, I really have no idea what I should be selecting anymore. And there's very few like full frameworks. They're all like little partial things and it's kind of like, okay, but they're partially opinion is to the partial things and only work with other specific things. But I don't have the list of that. And I was getting really confused. And so every website I do feels like it's completely new as a new technology and it's really weird. Yeah.

• 10:15 Kel

  You say that we've almost entirely moved back to plain old static sites with HTML and CSS.

• 10:19 Joshua

  We ran into the same problem we just gave up and started from scratch.

• 10:27 Edaqa

  And I can understand that. And I actually asked a question I think on dev.to recently "who would it be interested in a course on writing a web server and client without a framework" and there is interest. There's quite a bit of it actually.

• 10:38 Kel

  I do uh, I do generally prefer somebody else to write the protocol level things. I don't, I don't really like reading the protocol sheets of where, you know, every byte code goes. But yeah.

• 10:49 Edaqa

  Oh no... that for sure I would, I would, I mean I would just take an http library and take some JSON parsers

• 10:53 Kel

  that would never go down to that level. That's for sure. Exactly. And there's, I mean I do see that with like in the Go community, the, I've noticed the kind of the basic Go framework, there's just the http server and you're kind of on your own after that, you know, pick your framework and good luck, which brings you back to the whole which framework do I choose problem.. but you could do it from scratch.

• 11:13 Edaqa

  I think sometimes the frameworks just go too far. I mean I had the same thing when doing devops at a company. There's like all these like really complicated automated systems and what we ended up using, one's a simple tool called Fabric for python, which is really just a wrapper around ssh. And we just did that because it was like we could very clearly do what we wanted, execute things on a remote machine and it's stripped away layers of the framework, which we just didn't understand.

• 11:37 Kel

  Yeah, that's what I, I ran into that a lot with the Dev ops specifically. We're doing deployments. We actually did everything in batch files cause we were a Windows shop and that was its own brand of terror. But in the end it was simpler than the tools that we were trying to debug. Like we kept removing tools from our stack because it required more effort and more investment of time to learn those tools than it did to, you know, learn the little bit of the batch file that we actually needed. Yeah, we're all familiar with that part of the thing, that technology, so it wasn't as far of a leap.

• 12:08 Edaqa

  I think that's important to you to strip away tools and with the rise of things like npm and pip repositories, I think a lot of people are using libraries that really are only a couple of hundred lines of code...

• 12:22 Joshua

  We just stripped one of those out of our audio recording thing that I mentioned. I had been using a couple of libraries and then I realized that it's actually not much in here. I might as well just rewrite this and clean it up.

• 12:32 Edaqa

  Yeah. And I think that's important because if I look at some of these projects, they're usually buggy and part of the reason is because these simple packages have like a thousand dependencies and it's like they just don't work together and if the more you strip them down the better chance they have of working together like simplifying dependencies and strict streamlining them. It just reduces the complexity

• 12:52 Joshua

  That and by doing it yourself and not just pulling in 20 different libraries. You're learning a lot more and I find that is where I like to dive in a little bit deeper once I've kind of got a project fleshed out. I do like to go do some of that so I have a better understanding of what it is I'm building and why it holds together or it doesn't hold together and how that's going to improve or not improve things for end users in the end whether it's because the frameworks are just big and clunky or I just don't understand how they're working well enough that I can make it integrate well with my pieces or whatever it may be. Taking that extra step then is... I can see there being some benefit to the depth at that stage.

• 13:31 Edaqa

  Yeah. And I think, I think that's good. Uh, that understanding really helps. And I think for a lot of newer programmers, I think you get this misperception too about how much the framework is actually doing for you other than selling you that opinion and how to do it. Sometimes there's, there's not a lot behind it and it's good to strip them away. And I would actually give a lot of, so you know, credits to a framework that ever came out with a section in the manual of how to remove the framework. I think that'd be really impressive.

• 13:58 Joshua

  Yeah.

• 13:59 Kel

  that's actually my favorite, uh, some of, uh, I forget what the framework was now, but I did it a tutorial for, you know, another javascript front end to front end library. And the tutorial was essentially how to write this from scratch. And so by the time you're done, you absolutely understand how the framework works. And you know, if you dig into the code, you'll find all the exceptions and error checks and such. But by the time you finished the, like one hour tutorial, you just finished and wrote it yourself. You could write your own if you don't like the way that one works. And I thought that was a, the best way I've ever learned a framework

• 14:28 Edaqa

  That's, that's a really good idea. And I, I've been tempted to offer courses that way exactly that. Let's just write little frameworks and stuff. And especially in the web area, they're wrappers around, which are essentially browser technology and server protocol technology, they're not thick layers. They're very thin.

• 14:45 Kel

  A lot of the time it's just a normalize the differences in apis. I mean that was what made jquery so popular was just normalizing all the various browsers and the kind of disasters of the interpretations behind them.

• 14:57 Joshua

  Never ending job.

• 14:59 Edaqa

  And I mean, and it's great. They're great to do that. They're great to have the sources around and it's just, most projects never need that excessive level of normalization. And the browsers have also gotten better in some degrees in that. So..

• 15:10 Kel

  Yeah, I was surprised to, like I said, I give this, I give this talk about frameworks the other day and the feedback I got after kind of surprised me because everyone was coming up to say, oh, I didn't realize how simple it was to write my own framework. I didn't realize that was something I could do and they don't like they thought it was something that you only got to do as a senior developer. And you know, one of the first questions I ask is who here has a little file full of little utility functions? Because that's the begin.... your first framework right there. That's a framework.

• 15:33 Edaqa

  Yes.

• 15:35 Joshua

  That's how they get started.

• 15:36 Kel

  Exactly. And I think it is important though that people realize it's frameworks aren't, I mean there's a lot of magic in them, but the magic is just time spent and packaged and you know, pushed other people. You can do these things yourself.

• 15:50 Edaqa

  Yes. And I mean I think it's really important. People need to learn that and I think it's part of a learning path. You start by using them and then you should have this willingness to dig in and at the same time that shouldn't stop you from using the framework or if it's doing what you want and you don't need to change it. Go ahead. You said it's saving you time.

• 16:08 Joshua

  Yeah. When it comes down to it, as you say, the end goal is to build something that works for the user, whether it's solving a problem or providing some kind of value to them. If the framework gets you there and does it well enough, then that should be your primary purpose behind anything. Not just stripping out the framework for the sake of stripping it out.

• 16:27 Edaqa

  Yes, and that's, that's exactly sort of the point I went to in my article "nobody cares about your code" is that in the end, none of your users are really cared if you use redux or your own framework. It's like so far from their mind that it's irrelevant.

• 16:40 Joshua

  Yeah.

• 16:41 Kel

  So how do you approach a new project nowadays? Now that you kind of have this mindset, do you still, you know, do hobby it out? Do you do user testing first or?

• 16:50 Edaqa

  Um, it really depends on what I'm doing. I've been doing a lot of my own projects lately so I always do keep... I really do keep the user in mind and be thinking about that a lot. Normally I'm projects, I don't formally always go through the processes I recommend, like fully writing out the user stories, but I always have them back of my head and I always try to think like really, when I'm writing something, why am I writing this? What am I doing this for? And I think it really helps. It really helped me in my last position I was writing, it was really weird though cause I was writing a development platform so the users is a little bit uncertain who the users are and that that's just another complication when your users or developers, it's like mm,

• 17:30 Kel

  They have all these opinions....

• 17:32 Edaqa

  They have all these opinions they can kind of see through them and like what would their users users really want.

• 17:40 Joshua

  I do tell people all the time that actually when you're learning or when you're at that stage where you're developing the idea, you're trying to figure out what your end need, the best thing you can possibly do is to put yourself in their shoes. If I have a new client I will go in and I'll sit down with them and I'll tell them, okay, treat me like a trainee, show me how to do the job. I would not want to put myself in a position where I had to figure out what other developers do even though I do know the job already really well. That just sounds like a bad thing.

• 18:09 Kel

  It's a bit like someone telling you how they go about their writing style or you know with their, their process of a rough draft.

• 18:18 Edaqa

  So yeah... working with developers is a bit weird. And so my newer projects, I mean I have this food blog now and I, I really try to put myself in the position of people coming to my site. I'm like, well what are they trying to look for? What? What are they trying to do here? And I think it really sort of helps because on the technology side I have this big list as of this really listing cool stuff that he could be doing in a every single one of them think about... Yeah. But

• 18:44 Joshua

  Where do you see yourself starting to go toward with technology in the near or mid future? Well,

• 18:51 Edaqa

  I'm still a little bit up in the year cause last year I gave up on my language project Leaf, which was a language and so since then I've not picked up like an a major direction. But right now since I be doing a lot of writing in the last sort of six to eight months is I've really been focusing on writing tools. Now the reason I'm doing this is because it realized I come from programming and as much as we argue about how we do version control and how we get annoyed of tools of stuff compared to writing, we're like in the far future of version control and collaboration. And so I'm really sitting here every time I have to write something going like ah no.

• 19:27 Joshua

  You'd be amazed about once a year, particularly once we get toward Nanowrimo, we both say we should write a novel this year and then we open up all the tools. We should write a novel writing tool ..

• 19:46 Kel

  It gets bad when we start blogging too... Same story. It's like we could do this better...

• 19:53 Edaqa

  I'm serious... Then I started thinking I was always pushing it by. It's like, oh, it's probably just my opinion, but then I started meeting a lot of other writers who have, you're not programmers, not in the least, and they had the same complaints. It's like, well, I have a very consistent user story here. A whole bunch of them and it's like I would actually love to go in that direction and so for me, this is why I think it's the user story is important because when I'm thinking about the direction going, technology, the actual technology, I'd used to do this, this is not even in my head. I'm thinking about what I'd like to have accomplished first and what the users want and I would just choose what ever makes that happen.

• 20:28 Kel

  That's a good way of approaching it.

• 20:31 Joshua

  No, agreed. Just don't build tools for so much time that you aren't finishing books. Though, You've actually finished a book. You've done much better than us because neither of us have actually finished the book

• 20:41 Edaqa

  You have to write shorter books....

• 20:44 Joshua

  I'm beginning to think, so I get about 50 into one and then I think I'll just start writing that tool now. I'll just do that quickly and, and, and then the book never happens. The tool never happens or it does happen, but I never used it because I didn't write the book anyway.

• 20:57 Kel

  I usually get angry around the outlining process and how poorly. All the tools do just that and then everything kind of collapses from that point.

• 21:04 Joshua

  For me, I always make it 50 pages in there seems to be my hard limit.

• 21:07 Edaqa

  50 and 50 seems to be a little bit for a lot of people. So I got to my 50 then it got to a hundred and then realize I have nothing more to say on this topic. I think I'm done and I didn't feel the need to pattern or anything and I haven't really succinct style already and I'm like I'm happy with that and have no filler. I just, I'm fine. I'm okay with that.

• 21:24 Kel

  I actually like those styles of books.

• 21:26 Joshua

  To the point. Yeah.

• 21:29 Edaqa

  And if people... then I have this chance to get the feedback as people read them and see what it is and they have the chance to like write another one to focus on another area. Because realistically with a topic like what is programming, you have two choices I had to can do is I did make sort of a big outline or you can write a 10,000 page tome over the rest of your life.

• 21:48 Joshua

  That's out of date. By the time you get to the end,

• 21:50 Edaqa

  it's not a date but time you get to the outline.

• 21:54 Kel

  Like by the time I learned all these skills, they were already out of date and kind of, you know, not exactly what people want to hear anymore.

• 22:02 Edaqa

  Yeah. And that was also a challenge when writing was that I really want something that isn't out of date in a year. So I was like trying to talk about stuff without mentioning specific technology in it. That's really difficult. But I think it's super important because as we said before, if I write any specific framework name in there, you know, I'm going to be uploading a new version every six months.

• 22:23 Joshua

  And that's something that we were talking about with these new developers we were talking to that were asking about what to learn and things like that. And uh, we were highly encouraging them, not necessarily to learn a specific framework that's okay to learn those things and specific languages you kinda have to pick one. But it's more important to learn the concept because a lot of the concepts that I use every single day I've been using for 20 years, they haven't changed drastically. Loops are loops and arrays are arrays and buffers are buffers and largely they've been in use for decades now and won't be going anywhere anytime soon. And learning those things are really, really important. They're part of the core of what makes a good developer, not knowing the ins and outs of javascript or C++ or python or whatever it may be.

• 23:12 Edaqa

  Yes. And I think that's really important that we all learn the concepts and at the same time I think it's actually okay for so many, take a language at the first language and really learn it. Because if I think back to how I learned, I did not start learning by learning concepts. I just took a language and learn it and slowly I pulled the concepts out of that. And I think the moment you start learning a second language is when you're really start, solidifying what, what concepts do I really know and which ones are new and you could see which was a new, and then then it really helps.

• 23:40 Kel

  The patterns start to overlay and you're like, oh, I see how the loops are used in the different situations and you know. Absolutely.

• 23:48 Edaqa

  Yeah. And once you pull out enough patterns that says it's, as you said before, if you know enough patterns, why it's so easy to pick up a new framework and stuff because the frameworks are not 100% new. They're 95% overlap and all you have to do is map the pattern and your head to whatever silly names have given them now and you've learned the framework.

• 24:06 Kel

  Yeah, I had a large c# and vb.net project and I had a little cheat sheet between the two cause I kept forgetting what all the, it's like what's the keyword here? Oh it's shared. Not public... Shared. Really? Okay.

• 24:20 Edaqa

  And I do a lot of interviews too and I always get these interviews and people do this things and I would have this hard time doing an interview without a cheat sheet nearby because If I skip between languages. It's really like those basics of lists and stuff. I actually need reminders of how to do them but actually actually tell people it's like there's no excuse for that. And if I'm doing an interview I will actually prepare. I tell them you have to actually prepare, just memorize this stuff beforehand. I mean even if it takes you a couple of days, you have to know that stuff.

• 24:49 Joshua

  Kellen and I actually wrote a really good article about very similar concepts not that long ago about interviewing people on the, actually we're doing them and ourselves a disservice by asking specific questions like that because exactly that. If I walked into an interview, even one I would be performing. I might not know the answers off the top of my head because I've been working with a different language for the past six months or whatever it may be. And knowing the concepts is fine, but if they specifically ask me, how do you do this in c++ I'd probably just scratched my head for a minute because I haven't used it for a couple of years.

• 25:22 Kel

  Yeah, I'm a big fan of, you know, obviously giving them access to Google. Like, if you can search the answer within five seconds, well then that passed it, as far as I'm concerned, like if you know what to ask, what you're looking for and you know that's the answer that's as good to me is you having memorized it beforehand. So I do kind of put some emphasis that the interviewer should be kind of there to help pull that stuff out. There's not a whole lot of point of putting it all on the interviewee.

• 25:49 Edaqa

  I think so too. In a way. I mean I think people have to know the basics of how to work with loops and lists because even if I let them look it up, the problem is it's just going to take them too long and they're not going to make enough progress. So you do have to know some basics, but I actually prefix the interviews I do with basically like look, if you don't remember the syntax, just make it up and tell me what it does and move on.

• 26:10 Kel

  Yeah, that's great.

• 26:11 Joshua

  That's a really good way to do it.

• 26:12 Kel

  Yeah, set expectations.

• 26:12 Edaqa

  And I say, I'm never actually going to compile the thing I don't need to see compiled. I can just read it and tell you what it does. I mean, they're never complex enough that if I can't tell what it does from reading it then and then you have a problem. Anyways,

• 26:26 Kel

  Yeah.. I need to talk to you about clean code and..

• 26:28 Edaqa

  Yeah, exactly.

• 26:31 Joshua

  It's really bad is sometimes you have to tell employees these things as well. I had an employee for a while. He kept disappearing all the time when I'd ask him to go do something and I couldn't figure out what he was doing. It turns out he didn't want me to realize that he was googling things. And I finally, I figured this out and I said, you realize I don't care if you have to Google it. You're getting the answers right. You sorting it out and you're dealing with the problem and that's all I care about. Oh. And then he started performing about twice as fast because he wasn't running off to go Google things somewhere else.

• 27:03 Kel

  People get really afraid about messing up and you know the consequences of that.

• 27:07 Joshua

  No. Yeah, that's a big deal is making sure that they understand that there's no right way to do things. It's your way you do it and as long as you're getting it done, that's what really matters.

• 27:18 Edaqa

  Yeah. I think this morning and getting it done, how you get it done and if the code's clean, if you had to look stuff up that's fine. The faster. You can look things up even better. And I mean that's an essential developer skill now is how to write a search query to find what you want and, but I'm still, I still disapprove of people copy and pasting code, I still yell at people for that. It's like you can read it and rewrite it, but you should understand what it's doing. Otherwise you're just inheriting somebody else's defects.

• 27:43 Kel

  I've heard folks talking to like a coding schools. They went to the coding school and they're like you can totally copy from somebody else but you have to type it. That's the rule. And they, they always of course break the rule at like immediately and then nothing works and then the teacher goes, so did you copy that or did you write it, "no copied it..." But like the writing had really, does it just retyping it will help or at least get you half the way there?

• 28:05 Edaqa

  Yeah.

• 28:06 Joshua

  It forces you to start thinking about what exactly that code is doing. They're copying and pasting. You might get one or two lines out of it, but the rest of the other 20 just you completely ignore and shove in.

• 28:18 Edaqa

  Yeah. And I, it's very important. I think you understand the code at least for at least the purpose of security. You... I mean people stick weird stuff in there and

• 28:27 Kel

  Yeah, just thinking in terms of lessons, securities usually not one of the things I teach you the basics and it probably should be at this point,

• 28:34 Joshua

  At least some cursory knowledge of it would be useful.

• 28:39 Edaqa

  Yes. I think it's at least some cursory knowledge. Um, understand what security really means and understand... Yeah. How to deal with things. I think it's one of these unfortunate things with the rise of un-typed languages. I think it causes an issue for security that a lot of the lessons you could do in security are not applicable to python and Javascript because they don't have that types system. And I think you miss out on some of that. It's unfortunate, but it happens. You can get right stuff faster. So it has that advantage.

• 29:10 Joshua

  Yeah. And just even beyond that, the basic concepts of where data's flowing, where when it's at rest, when it's in transition. And most developers I talk to now just have no concept at all. They don't understand the protocols are using. So they're building all these huge web APIs and things like that. They don't understand the basics of http at all.

• 29:32 Edaqa

  And I think this is the point of going back to understanding the framework and being able to write without a framework. As you know where your data is going and you'll know type of areas you can actually get in it and you, you don't have to rely on somebody to provide your security. Cause that's never going to work. You have to write it yourself.

• 29:50 Joshua

  In there are examples like it's stupid where the

• 29:52 Kel

  In fairness, there are examples like http where the amount of stuff you would have to do to rewrite it yourself would be a challenge. Like you probably want a group of folks maintaining that and that's of course where I put some frameworks I think are in a good spot is for security and maintenance of security.

• 30:05 Edaqa

  I think for things like strict protocols, http, I think that makes sense. But I mean more like the higher level things like actually doing the actual server framework and get and put... And security is one of those. One thing that bugs me every time I go back to it is I want to framework that just says look, just give me my user module does everything. But the last time I did this even two years ago, none of them actually provided like secure logins, secure cookies or anything like this and I have to write my own and I'm just like, but this is weird. Why am I writing my own? It's like this means that all those sites out there, I know they didn't write their own, they're just not secure it.

• 30:42 Joshua

  Yeah and there's just so much to security now. You would think that that, that that's becoming one of those things like http that actually the core parts of the protocol really should be wrapped up in a nice package.

• 30:52 Edaqa

  Yes.

• 30:52 Joshua

  So we're not all writing our own and it reinventing the wheel and missing lots of conflicts. I'm not a security expert. I know it reasonably well because I've been forced to, but I would never declare myself an expert. I would much rather defer to an expert, particularly with how frequently it changes, how quickly new things are coming up. Then becoming a problem that weren't problems a week ago.

• 31:15 Kel

  I mean at some point in our careers, we kind of were experts. That was a part of one of my first jobs as you know, dealing with security issues on desktops. I mean it wasn't from the software perspective, but more from, I mean still software but not from the code perspective. I, you know, pushing patches and maintaining security on machines and that's changed in the last decade. Like even that is already changed and that's not even down at the level that that folks are really attacking and hacking out. That's you know, a couple of layers on top of and all of that's more or less gone and we've replaced it with other things so.

• 31:44 Edaqa

  Well I think security is an interesting one cause you said that the level, the attack at is that... For hardened systems? Yeah they're attacking.... it's very fascinating. I love reading the way they tack. There's some really fascinating ways they do it, but I think most systems are still breached from very, very high level things. It's like they're not...

• 32:01 Kel

  Like the person reading the email.

• 32:05 Edaqa

  We're not challenging some of those attackers very much.

• 32:10 Kel

  Very true. Yeah and I think that's, I would actually like to see that as part of like a lot of programming is like a intro to hacking 101 and just let's see you, this is what it looks like. This is what the actual other side of things looks like. So you can kind of get a feel for the type of effort they have to go through to hack your system or the types of effort they don't have to go through to hack system.

• 32:28 Edaqa

  I saw course, uhh... One of the security guys and Twitter always says he has, he has a course and you hack a website and that's uhh, it's very interesting. You actually, you take that side and you show how to break the website. He's got like 15 failures and you have to go through and find them.

• 32:43 Joshua

  Nice. I think that would actually be really useful for a lot of developers should be kind of a requirement and these bootcamps and things like that. Certainly early on before I was even thinking about it as a career. Just things like video games, trying to make Doom do things that it shouldn't be doing. Learning and thinking about how you would get around various things and just putting yourself in that mindset and understanding how that mindset works is actually really helpful because you start to think about where your data's flowing and what weak points that are in that because you've done it yourself in the past. Not necessarily anything dodgy, but in that case I just, I wanted to fit in Bill Clinton's head and Doom or something like that. But it's the same concept and understanding that gives you a different point of view, a different perspective when you are developing software. So you start to think about, "actually what if somebody puts Bill Clinton's head in this and how can I avoid allowing that?"

• 33:39 Edaqa

  I think I've got a lot of that experience too. Cause I did some, I worked at a startup as the director of quality assurance and we did testing and all that stuff in process management. And it really got into that and the testing looking at like, well how can we, how can we break this system? And that's actually once you really get into it, that's not a challenge. The question was how can we act like a user break the system.

• 34:02 Kel

  And how can you mitigate when you do break it that it's not a security risk, it's just an annoyance. And ...

• 34:08 Edaqa

  Yes, and, and I think that really got me into that mindset as well as really thinking from that side and that, that reinforce that user side.. Really looking at, well how are we really going to be using this system? How can we sort of break things? And I found one way. I just, I um, I was a curious when I was doing code review and cause I did that in the same job and one of these things there was using a hash table to make map entries and they weren't they were using a hash table we want a value to just overwrite the other one. And it was using stats rights and there was the hashes would never override. And I'm looking at, it's going like, yeah, but if I have short enough input strings because these are coming from a user, we might have overriding hashes. But I had to think it's like, yeah, but a user isn't an intentionally just create these simple strings. So what I did is I figured out if I used all the country codes, the two letter country codes, some of them had conflicting hashes. So I created an example that just looked like two random things like France and China overlap somehow and totally looked like a user example and actually caused the program to crash then because it had the same hash.

• 35:14 Kel

  Those are the kinds of types of errors. And you're like, oh, I didn't think about that. There was no reason to think about that. Why do I have to fix this?

• 35:20 Edaqa

  Yeah. And it's, it's, and I think that's the greatest part is just when you're programming, you often don't think about it. You often think it's like, you know, this isn't likely going to happen. But I think when it comes to security, we have to start taking, the view point of like this is probably going to happen.

• 35:37 Kel

  Yeah. And I've heard that as a recommendation to always just kind of assumed that at some point it's going to fail. What can you do to mitigate that risk to at least some extent? Like what can you be prepared for? How can you, you know, soften, soften a leak.

• 35:51 Edaqa

  I'm a big proponent of defensive programming and I'm pushing out a lot now and I have a chapter as sort of my book on that as well as that defensive programming helps a lot for security because the moment you detect anything, which is suspicious, you immediately kick it out of the system. Like, no, I don't know what's going on. But we didn't intend for that.

• 36:09 Kel

  Yeah, and that's kind of unfortunately, it's a little bit of the backwards of the user first because chances are you'll fail, you'll get false positives on that. You know false attack. It's not actually attack it sees or just doing something silly and you boot them out and giant red alerts or something, you know, give an error message. But on the other hand, like you said, it's not going to do anything awful.

• 36:30 Edaqa

  Yeah. And I think that's really started. I think nowadays that's, it's almost sort of the preference is it's like do you risk and knowing a few users or leaking 2 million database records,

• 36:42 Joshua

  Oh yeah, absolutely... Certainly I know every time my credit card pops up saying, oh, we've had something go wrong, then we had to decline everything under the sun. I think, well that's annoying, but okay. But I'd much rather that than, yeah. And I think most people are kind of getting to that point and they're starting to understand that it's not just credit cards. It is everything.

• 36:59 Edaqa

  It's everything, yeah.

• 37:01 Joshua

  I was just reading something earlier about the TV license in the UK. Kellen got me... don't get me started on TV licenses..... But they actually had a breach. It's something most English people just, they pay the TV license because that's what they've always done since the queen said they had to 50 60 years ago or whatever it may be and nobody thinks twice about it, but they actually had a huge breach not that long ago and they lost tons of people's financial information, personal information, and people are starting to realize, oh wait a minute, all this information is somewhere, and they're starting to think about these things where they weren't before. They were worried about the credit card and fraud with that. We've been worried about that for a long time, but they're now starting to realize it's not just credit cards, it's all sorts of other things.

• 37:47 Edaqa

  Yeah, and I think people need to start thinking about that more when we need to start holding companies accountable for it. And I think that's the biggest issue now we have these data breaches and nothing really comes of them. The companies that get a slap on the wrist and they just keep going. There's absolutely no incentive to protect data right now in terms of economics. And I think this is very, very unfortunate. And, and um, I don't know if that's something programming can change on its own because again, it terms a prioritization. Somebody is going to do the risk analysis and somebody is going to say, we'll look at these big breaches here and these big scandals, nothing came with them. So I mean...

• 38:21 Joshua

  Well haven't you heard GDPR because there's all of that magically.

• 38:25 Kel

  It's tryin'.

• 38:28 Joshua

  It is trying, that's for sure.

• 38:30 Edaqa

  It does something, I think something went wrong with it. I think if people would implement it according to the way it was intended, it'd work. But now it's just like, hey, if you want to use your site, you agree to everything. And the other sites are just like, oh your European, sorry, we don't have content for you.

• 38:45 Kel

  As a developer though, I do appreciate taking a iterative approach at things like let's try this and then let's try... Coming, you know, see how it goes. And then see what happens.

• 38:54 Joshua

  I would like that if I had any faith that they were going to try anything. Remember the cookie law right... I mean... That hasn't been iterated upon at all.

• 39:02 Kel

  Yeah, there are days, I wish there were more like programmers but

• 39:06 Edaqa

  Government is terrible refactoring, right?

• 39:08 Joshua

  Yeah, exactly.

• 39:10 Edaqa

  They just keep adding new code.

• 39:12 Joshua

  Oh yeah and none of it compiles. Just ship it anyway!

• 39:18 Kel

  And that is a bonus of a more folks learning to program. As you kind of learned to think of those things in a more iterative approach, more more willing to accept failure, compilation failure like, oh, it's just a bug we can fix that.. Like it removes some of the, some of the pressure to do perfect on the first track is it's never going to be perfect on the first try.

• 39:36 Joshua

  If all lawyers and politicians were forced to learn how to program first, I think it would help a lot

• 39:43 Edaqa

  Well Yes...You'd have this. It's like that the, you know, the new environmental protection law is like it has some rough edges but you could see in the columns and the law. We programmed Doom right...

• 39:55 Kel

  We might be a little biased on this subject, but I was gonna say if you had anything you wanted to plug or you know, talk about before we wrap up, but...

• 40:05 Edaqa

  So I've got my book, I wrote my book, what is programming? And it's a lot about what we talked about. It's about everything that a programmer is not just the code but the people skills, understanding users and also I have a big section and taking care of yourself because ultimately if you fail, your code is going to fail. And so I have this book. Please read the book and you can check out my website and follow me on Twitter as well.

• 40:28 Joshua

  And that book is available on all the normal outlets, Amazon and Barnes and Noble. And various other places

• 40:32 Edaqa

  Just Amazon right now because I'm taking advantage of the 70% royalties.

• 40:36 Joshua

  Okay, fair enough. All right, well we'll put some links up for that so that it's easy to find those. Uh, we really appreciated having you on. It's been great. Thank you very much for approaching us for once!

• 40:50 Edaqa

  Okay. I thank you. It was. It's been fun and I really liked the show.

• 40:55 Joshua

  All right, well, thank you very much. I will put some transcripts up at gettingampsdone.com. Please be sure to check out my website at joshuagraham.info. And Kel's website at piffner.com. Also make sure that you do check out Edaqa and his book. I will post some links of for that in the transcripts as well. Until next time, thanks for listening.