ScreamingBox Technology & Business Rundown

Speakers: Dave Erickson, Botond Seres and guest Robert Martin

Dave Erickson 0:33

Welcome to the ScreamingBox technology and business rundown podcast. This month's podcast is our second was Robert Martin, also known as Uncle Bob, if you missed last month's clean code basics podcast with Robert, please go to podcast.screamingbox.com If you wish to listen to it, and I know you do with decades of programming experience, Robert is considered a leading authority on clean code and agile software development. And some of his instructional videos have had millions of views this month Botond and I will go into detail with him about techniques, technical aspects and the applications of clean code.

Botond Seres 1:09

Oh, I was watching one of your lectures, and something struck me. So you touched on a topic saying that at some point in the future, our job is going to be legislated. And one of the points you brought up is, you know, we have to uphold a set of standards and a set of ethics. So I think the most famous example of that would be the hyporaticals for doctors and it has one of the most iconic lines in it, which is do no harm. So I was wondering what you think could be a similar, or equivalent statement for coding?

Robert Martin 2:03

Yeah, I just wrote a book on this topic. It's called clean craftsmanship, right. And the final chapters of that book are a possible oath, a set of promises that software developers could, could take. And of course, the first one is do no harm, do no harm to behavior, do no harm to structure, do no harm to your clients, that kind of thing. I, the book itself goes through standards, disciplines and ethics. Right. And it does that in the reverse order disciplines first, then standards. And then finally, ethics. And ethics is about the oath that you might be able to take. I think that's important because our society has grown utterly dependent upon us. Without programmers, society doesn't work anymore. This was not true 30 years ago, but it is true today, nothing happens in our society without software being right smack in the middle of it, You can't tell the time of day, without 100 million lines of code running on your wrist, you can't call your wife, without 500 million lines of code running in the palm of your hand. You cannot drive your car without 100 million lines of code in that car controlling everything including the dam breaks, right? You can't do anything in our society, You can't microwave a hot dog without code being smack dab in the middle of it all. Our society runs on software. And we'd like to think our society runs on oil if it doesn't run on software, because you can't get the oil without software. So we programmers are the ones at the base level. We're the little atlases holding up the globe. And that's why we're doubling at a crazy right to because it takes more and more of us to hold up this crazy superstructure of software that we have created. And society does not quite see this yet. There have been some big hits, some really big hits, the 737 Max was a great big hint. You know, that was a hardware software problem. But it was a software problem that killed several 100 people. Healthcare.gov, that was a big hint. You know, that was a fiasco that eventually came around, but during those first two months, that was it was hell, as we've seen other disasters like

Botond Seres 4:30

For those who might not live in the US. What was that fiasco?

Robert Martin 4:34

That was the American Affordable Care Act, which was the beginning of universal health care in the United States came around in 2013. And there was a law passed by the government and signed into law by the President of the United States that there would be a website running on October 1, 2013. And now, regardless of the fact that it's incredibly stupid to name the date by law.

Dave Erickson 5:08

Obviously, a developer didn’t write that law.

Robert Martin 5:14

It turned out that it was not ready on October 1, 2013 and that did not stop them from turning the damn thing on. And by turning it on, and seeing the horrible fallout, it nearly derailed that law. The Republicans rose up in righteous indignation and nearly cut that law into pieces and didn't quite pull it off. The President of the United States at the time was Barack Obama and he very nearly put a new cabinet position, reporting to the President, the CTO of the United States of America, which is a terrifying thought, right? What the heck would a cabinet position CTO of the United States of America; what would that person do? “Wow, C+ seems to be a pretty good language. I think everybody ought to be doing C+. Everybody should probably follow the spiral model, the beam spiral model? Yeah, I remember that, we should turn that into a regulation; I think we should hire a bunch of regulators to go out there and examine the way software developers work.” So that was a terrifying one to me. That's what I worry about. I worry about the idea that as society becomes ever more dependent upon us; they are going to want to regulate us. And if we are not there with the rules, first, they will invent dumb rules to deal with, right. So we've got to be there. First, we've got to have the rules ready to give them like the doctors did. You know, the Government came along eventually and regulated the doctors and the doctors were there and they said, Yeah, here's the rules. You want to turn them into laws? We don't care, because we're already following these rules. That's where we need to be.

Dave Erickson 7:03

We need the developer's version of the Hippocratic Oath, right?

Robert Martin 7:07

Yes, yes. And all of the structure below that all of the evaluation and enforcement structure somehow we've got to get that into our industry and I have no idea howI don't know what that looks like.

Dave Erickson 7:21

Well, that's an important concept because, you know, look, I think that ethics have such a critical role in any company right, but let alone a company of developers. You don't want bad actors in any kind of development team. You want people who truly are there to make things better, because as you said, I mean, I personally think the Boeing Max, 737 Max is really the really descriptive way of what can happen when developers don't do the right thing. Right? When they're not looking at the ethics of it. And for them to say, look, this is okay. And it's okay, if we put it in an airplane and the airplane has an issue, right? It just isn't the right thing to do. Right. And I agree with you. We, as developers, and software companies need to have our ethics in line first. And we need to have all the infrastructure that supports those ethics. Because I think you're right, I think governments aren't going to say, look, what developers are doing is affecting millions of people's lives and they have to do it the right way. I mean, Tesla Autopilot is another one that really concerns me. You know, those software writers better be really precise. Because, you know, if you turn that on, and it doesn't recognize that there is a cat in front of you, you know, flat cat, right? And so, and more and more that's happening, more and more independent companies are developing products that are software based, that affect the lives of millions of people. And I myself as a consumer, am asking the question, did the people who write this software do no harm? Right? Did they do it the right way? Can I trust my life with this software? And I don't think people understand that that's really the question they have to ask about some of the software that they're using or even if they don't realize they're using it. Right.

Robert Martin 9:35

I am a pilot. I fly a small plane around and in my plane I've got a very nice autopilot . It's really well done and does a spectacular job. The autopilot can fly me across the United States through all the way points. It's really very nice. And I watched that damn thing like a hawk. I don't trust it for a minute. I know it's gonna screw up in just a minute at just the right moment. And you know, sometimes it does. Sometimes it screws up for, for all the right reasons, right? Because it reaches a condition that it cannot deal with, it just shuts itself off. And all of a sudden I'm flying the plane. I better be mentally prepared for that. Right? So I don't, I don't mind autopilots like, you know, even at Tesla Autopilot, I don't mind that as long as I got my hands on the wheel, my eyes are on the road. And I expect that thing to fail at the very next moment.

Botond Seres 10:27

This is exactly what I'm afraid of. Because many, many manufacturers are like, okay, next thing we do is we remove steering wheels from the equation.

Robert Martin 10:39

See my head explode? If I'm near a road that has cars with no steering wheels in it. I will stay away from that road, utterly.

Botond Seres 10:52

Get your pilot’s license. Right. Bobby, you’re quite outspoken about how you treat comments of failure of clean code. And I am on the complete opposite side of the fence. So I love comments, even the dumb ones. Like initializing this variable. I love all of them. Yeah, I just love all of those. So I don't mind. So what am I trying to ask here? So what do you think about those who use clean code as an excuse to never write in the comments, and we are talking about the kinds of devs who write terrible codes.

Robert Martin 11:43

I've said you should never write comments. So I write a lot of crap code, and I don't bother at all. Yeah, obviously, that's not a great idea. So first of all, the way I look at it, and I explained this before, but you know, if you can express yourself, well, in code, you should not need to comment. On the other hand, when you cannot express yourself well in code, and that happens all the time, then you should definitely write a comment. So if you look at the code I write, there are comments in it. They are not a lot of comments, they are not line by line, generally speaking, they are not put in, in a regular way. It's not like every class has a comment. It's not like every function is a comment, but you will see a comment coming in from time to time when what the code is doing cannot be properly described by the code itself. There's something extra going on, some funny little thing going on, something that had to be set up just right in order for this code to work, some larger principle that the code is following, but cannot express by itself. So yeah, you will see me writing comments. Just, I don't do the dumb ones, right. I don't do the you know, “I++incrementI Yeah, I=0, reset”, I am not doing that.

Botond Seres 13:02

Return reset, return reset. Yep. So what is your opinion on like, X amount of comments or Java docs or those that end up in IntelliSense?

Robert Martin 13:19

Those are good.Yeah. I mean, if you have a sa.., a library that you are trying to offer to the outside world, an API that you're trying to offer to the outside world, putting together an external document, like a Java doc or something like that, is a very good idea. All right, because people will want to go to that document, they want to see it on the IntelliSense, they'll want to hover over the function and see the document pop up, all of that stuff is good. That's there's nothing wrong with that, as long as those comments amplify the signature of the function, the signature of the class. If the function is self explanatory, then if you hover over it and see a document pop up, and the document simply says exactly what the function name is. That's not very helpful, but in general, I think those are good ideas inside the team, where you've got a whole bunch of functions that are not externally exposed; they're just inside the team and the team knows about them, I don't want to see that kind of stuff. I don't want to see JavaDocs there. I don't want to see external documentation. I want the team to know those functions. Right. So you don't need a lot of that specialized stuff for internal code. External code. Yes. Internal code. No.

Botond Seres 14:42

It's so true. And it's a real thing in teams these days. So usually, the people who have written the code are no longer there. And no one has any idea what some of the functions do. And that's where I find them incredibly useful.

Robert Martin 14:53

So I agree with you there. However, I think that's a much more fundamental problem. We tend to take our teams and throw them around, throw these people over here, take these people over there. Don't ever let them get used to each other because oh my god, they might revolt. A good team of developers stays together. There's continuity to the team. Yeah, okay. Occasionally someone comes in, and occasionally someone goes out, but you've got a nice kernel of a dozen people, those people can get used to each other and gel in a way that makes them really productive. And it is very what's the word? Harmful, that's a good word, to the, to the team, to scatter them and re-gather them and scatter them and re-gather them all the time. So I want a team that knows the software that it's working on so well, that you don't need those internal Java Doc's just me.

Botond Seres 15:54

Yeah, I understand. Completely. I don't really understand why job hopping has become so common. So. I mean, I do understand. Yeah. So I mean, you stay at the job for two years, inflation has already got half your money, like in my country anyway. So it's like, when you leave, you can double your salary every two years. So yeah, I see the points. But I do think it's a fundamental problem. Especially

Robert Martin 16:24

You gotta ask yourself why that happens. Why do you get more money by changing jobs? You're more valuable to the first company, then the second company?

Botond Seres 16:35

Yeah, that’s a side I don’t understand. Like, why?

Dave Erickson 16:38

Well, some, I mean even now, if you're gonna see a lot of developer churn in the next year. You've now eliminated, you know, several 100,000 developers from the global developer pool with the elimination of Russian developers. We've never used Russian, and so, it's not an issue. But basically, the Ukrainian developers that we had a couple of, they're not working either. So, you're taking your global developer pool, and you're not adding new developers, you're subtracting developers. And at the same time, 30% more new projects have just entered the market in the last month, right? So people are just, it's crazy. The developer rates are growing so quickly that developers are just moving from job to job because they literally can double their salary, just with one job move. There’s going to be poaching and hunting developers; it's going to backfire. It's going to create a big problem. And that's kind of why the focus from my perspective, as a business owner, there's an emphasis in clean code. A focus needs to be really made in that because you got to make the developers lives easier, they got to really like doing what they're doing. It can't be filled with frustration of, Oh, my God, I can't, you know, this person wrote the code, and I can't understand what they're doing, I have to spend 20 hours figuring out what they did, right? It's really got to be tighter and better and more efficient. And I truly believe that clean code principles, and the structure and the ethics of that are really what's going to differentiate companies from each other, right. And those companies who follow these philosophies, and their developers follow these ethics, they're going to be the ones who are able to succeed and expand and grow. And yes, there's gonna be developers that are kind of thrown to the side because they don't believe in them. And they do it a different way. And they can go work for some other company. And that's perfectly fine. And I really think that companies need to really focus on this concept. I have a strong belief and not just one of the reasons why I chased you down and tried to get you on this podcast.

Botond Seres 18:59

Like, there's a piece of wisdom or a quote that I love. It's one of the reasons people hate me, right? I always have to say that.

Robert Martin

No one hates you, Botond.

Botond Seres

But I mean, it's not the literal way, but like, it's a strong dislike of the statements from a managerial standpoint anyway. So I always say that slow is smooth and smooth is fast. And I tend to think that maybe Bob here could agree with this.

Robert Martin 19:34

I certainly agree with that. It echoes the mantra that I like to use, which is, the only way to go fast is to go well. There's another fella by the name of Brian Merrick once wrote, what was it? In software it never pays to rush which is really true, right? So yes, there is this. There is this idea that if we slow down a little bit, we'll actually go faster. If we just take a deep breath and say, okay, all right, we don't need to, we don't need to work 60 hours, we don't need to flail around horribly, we don't need to just, you know, code and code and commit and commit, slow down a little bit, and then we'll go faster, and we will go faster in the relatively short term, you know, a measurable amount of time a week or so. So yeah, I certainly agree with that. And by the way, this is like the oldest rule in the book. Everybody's grandmother told them this when they were three years old. Right. Anything worth doing is worth doing well.

Botond Seres 20:42

How did you lose this? Everyone's like, Okay, we have to cope with everything by yesterday.

Robert Martin 20:51

Well, you understand the business has needs and business has dates and those dates are real. And there's tough stuff behind those dates. And the thing to understand is that you will make those dates by slowing down and going more deliberately than flailing around like a crazy man. I like to tell this story. Imagine that you are on the operating room table. There is a heart surgeon working on you. You're having an out of body experience. In the spirit realm, you are looking down, and you are seeing the doctor operate on you. How do you want that doctor to behave? Do you want that doctor calm? Cool, making deliberate moves? Never looking at their watch? Never looking at the time disciplined, orderly? Or do you want them*@^#$*? How do you want them behaving?

Botond Seres 21:51

You just described Surgeon Simulator as the greatest game in the past 10 years. Yeah, I couldn't agree more. So one of the things you mentioned in the talk is that function could be polite. And one of the measures of politeness was to have every call inside that function at the same indentation or the same level of abstraction. I think that was the more important one. So this is something that I think would be interesting for anyone, but how do we define levels of abstraction? So like, usually what we do is like API, VLL, and then repository; or something like that. But we kind of need to define more levels inside those frameworks, right.

Robert Martin 22:46

So I define a level of abstraction as the closeness to inputs and outputs. Low level things are close to the IO, high level things are far away from the IO. And by that also means low level things are close to the computer architecture, the memory, and high level things are very far away from that. And you can look at that by the function call hierarchy, just follow the function call hierarchy down and at the limits at the lowest level, it's talking to IO devices. And it's talking to the computer memory. And it's doing low level operations at the computer hardware level. And as you climb back up that you get into higher and higher level business rules, that's the way I define level. So level is this really interesting idea, right? That you're backing away from the details, the low level IO, computer architecture stuff, you're getting to higher and higher level concepts. And so a polite function is a function that stays at its level. It doesn't go up and down. It just stays at its level. And the reason that's polite is that when you change the level inside of a function, the reader, the person who's reading the code, has to push the current level on their mental stack so they can deal with this little level thing down here. Like maybe there's a no check, that's a really low level thing, because it is a computer hardware kind of thing. So there's another check in like, Okay, what's this little check about? Okay, figure it all out. And then once they figure that out, they can pop their mental stack back and bring the previous level of abstraction back engaged, and they can reason more about the software. And the problem with that is that we do not have a mental stack. Human brains do not have a stack built and we're not good at this. We're not good at pushing a context up on our mental stack. In fact, it's an emotional roller coaster. And you know this, if you've ever gotten focused on something, and had the phone ring, and you're mad You're angry because the phone rang and you know, the amount of work it took you to get this mental model in your head is now gone. And you answer the phone, it's Yes, honey, I'll bring home some bread. And now you're back into trying to recreate the mental model that was in your head. There is no mental stack. Every time you change the level of abstraction, it's an interruption. And it's rude. And so we try to keep our functions so that they're all at the same level; nothing's getting interrupted, nobody has to worry about this dumbbell check. Okay, then I'll check, well, look, here's markers somewhere else, but at a lower level function where it's appropriate. And we can all stay at the same level of abstraction.

Botond Seres 25:42

Let me just circle back to another question that I had was just inspecting the level of indentation and a certain file is it's like 1,2,3,5, or, or quite typical cases, like 20 levels of indentation? Like, why don't our IDs just immediately underline every single line that has like 20 levels of indentation? Why is that? Another thing?

Robert Martin 26:13

Yes, the IDE should refuse to respond to the Tab key once you're a few levels in? No, no, you cannot go any further. There are tools that you can get that are reasonable tools for inspecting the code. And they'll tell you lots of very interesting things. Indentation is really similar to the cyclomatic complexity metric. And you can get tools that will measure that for you and tell you every function, what is the cyclomatic complexity, what's the volume, what's the line weight, there's a whole bunch of very interesting metrics that you can get, these are worth looking at. They are never worth legislating, you don't want to,for example, you do not want to put a rule in that says, You're not allowed to check in a module. If it's got more than five indentations, that's not a good rule, you're not allowed to pass the build, the build will fail. If you've got a function with more than a cyclomatic complexity of six, right? These are bad rules. And they're bad rules, because managers will use them. And managers don't understand what they really mean. My favorite of these is code coverage. If you've got a nice suite of tests, and that suite of tests is covering the code pretty well, and you run a coverage tool, and it generates the metric, what you what you do want to do is run that tool and look at the metric and understand why certain things aren't covered and why certain things are, what you don't want to do is say, Well, you must have 80% code coverage. And so we're gonna fail the build, if there's not 80% code coverage, that's a terrible thing to do.

Botond Seres 27:58

That's what everyone does.

Robert Martin 28:02

It's dumb, because there is a way to get 80% code coverage, which is to take all the assertions out of your tests, which is what they will do if they have to. So you don't want to incentivize that kind of behavior. And it's not a management metric anyway, so managers shouldn't even be looking at that metric. That's a very complicated metric. Software developers can understand it. But it's not as simple as Oh, 80% of the code is tested. That's not what that means.

Botond Seres

That’s funny.

Dave Erickson 28:34

I want to go back to that just for a second. Botond, you know, indentation to someone who isn't a developer. They're like, why are these guys talking about indentation, right? But it kind of goes to this concept of like, the shape of code. You know, I did get a computer science degree, I'm going to date myself. I actually worked on a UNIVAC computer once with the card stack and did some programs with that. And my first personal computer was an inside at 80 with a front panel lobe. You know, so just kind of harken back to that. And I learned COBOL and Fortran and Pascal and basic and I did you know all that and I got my computer science degree and then decided, oh, I should go into business. I got a business degree instead and went that direction. But, you know, for those who haven't really coded, you know, this concept of indents the shape of code. Actually, as a Fortran programmer, I looked at the shape of code very carefully, because it told me where things are happening, right? I don't know if in a lot of modern code nowadays, the shape of code means something. But that's where it comes back to this concept of are there enough indents and is it been indented correctly? There's also patterns right even in code you can recognize certain types of code of certain parts. patterns and design patterns, but in coding and in clean coding, shape of code, design patterns, that type of stuff. How is it connected to clean code? Or is there an importance there? Because it seems like there is.

Robert Martin 30:16

There's certainly a connection with design patterns. Design Patterns are a set of crystallized knowledge, right? And there's this funny meme out there right now that's trying to say that design patterns are out of date and archaic and they were really invented because their languages were insufficient. Now that we've got better languages, we don't need design patterns. It's complete nonsense. I don't know where these guys come up with this stuff. But that's utter nonsense. The book, the design patterns book is a tremendously valuable resource. Every software developer should have it, every software developer should know those design patterns by heart, right? So that when you see the word visitor, or you see the word, composite, or you see the word decorator, the design snaps into your head, and you know exactly what they're talking about. So design patterns, yes. Now, shape of code, that's another matter, right? The shape of the code is that indent shape, where the left edge of the code looks like a crosscut saw, right, you're gonna cut down a tree with it. Why do we like that shape? Because we do, we like that shape. Right? Like I said before, I wrote a 3000 line C function that inside and out when I was a younger man, I knew that code by that shape, I recognized where I was in that code, by that shape. If someone said to me, Bob, you've got to do X, Y, or Z, I would say, Ah, X, Y, and Z that's in the third indent after the big comment block. And I would, I would scroll down to the big comment, block and count 123, there it is, that's XYZ and I would do whatever needed to be done. So I knew it geographically, like the back of my hand, I knew the shape of that code. That is not a good thing. It was very comfortable for me. Great for me. But for the next guy who comes in, he doesn't know the shape of that code. He doesn't know where x y, z is, he doesn't know it's in the third indent after the big comment block. He's got 3000 lines of code, he's got to internalize. And, and that's a very comfortable situation to be in. Wouldn't it be nice if there were a little tiny function somewhere that said XYZ. That might be helpful to that poor guy who just came in and to do XYZ? Oh, yeah. There's the x, y, z function, instead of, you know, third indent after the big comment, block, Bob, Bob, where's that code? It's in the 3rd indent. You don't want to be doing the shape of code that way. Why do we like to shape this funny in and out shape? We really like it, it's recognizable in our brain and can kind of go oh, that's that part and there's this geographical recognition going on. And I think it has to do with this, if you take that shape, and you rotate it 90 degrees, it looks like the horizon. And human beings, creatures who evolved on the savanna knew their position in the world by looking at the horizon. We still do that today. Right? So there's something about that, right. There's this back of the brain, this hindbrain comfort that comes from seeing that shape of mountains and valleys. And oh, I know where I am.

Dave Erickson 33:23

It actually makes a lot of sense we are very primitive creatures.

Robert Martin 33:28

When things make sense you’re in dangerous territory,

Botond Seres 33:33

But also answer your question in a completely different way. Then just think about this, imagine that you're reading an ebook, right on your phone screen, and you’re reading, reading and everything is in the same, same position, every line begins at the same position. They see like half a page that is empathy. Right, but turns out, it's not that you just didn't scroll far right enough.

Robert Martin 34:00

Yeah, I have a fundamental rule, right. And you should never have to scroll right. This is amazing. Basic. Manners, real good manners, right? Never make anybody scroll right.

Dave Erickson 34:16

We mentioned AI a little bit, you know, AI looking at code, AI writing code I don't know. So people confuse AI. They think of AI as artificial intelligence. And they confuse it with artificial consciousness. Right? They're two completely different concepts. Right? Yeah. If we're talking about, yeah, if we're talking about clean code having a component of ethics, I don't know if artificial consciousness or artificial intelligence could ever review code because it couldn't recognize the ethics of it. It's not, it's not conscious. It's mechanical, right. Artificial Intelligence is basically a mechanical construct. But it can replicate code, it can generate code, whether that's clean code, whether it's even good code is really the question that people are asking of it. But what do you think about how AI may affect development and coding and clean coding? It is mechanical, so rules can be programmed into it, it can generate code that fits these rules, is that enough to create clean code? Or is that just kind of like what artificial intelligence is a mimicking of something.

Robert Martin 35:36

Whenever a machine creates code, it has done so because some human has given it a description of the code that must be created. The code that has been created is now the binary. And the description that went into it is now the source code. The programmer is still writing source code just at a slightly different level. And you shouldn't have to look at the code that it generates. It doesn't matter if it's clean or not, you're never going to touch that code, I hope, you're never going to edit that code, I hope, what you're going to be editing is the description that feeds in. So that is the source code and what the machine generates is entirely irrelevant as long as it works. That's the rule that we have used for 70 years and that rule doesn't change. Just because we put the words machine learning or AI in the front of it, we shouldn't use AI, we should use machine learning as tools to help us write better code. But that code is on the far side, not the output, it's on the input side to the AI, not on the output. Same is true of all the diagramming programming languages, the two dimensional, you know, UML diagram, kinds of programming language, exactly the same thing, doesn't matter. What they generate matters, what you put in, the human put stuff in, the machine creates what goes out and there will always be programmers because somebody has got to put that stuff in. And those are what the programmers do.

Dave Erickson 37:08

I know, you know, just by the nature of programmers, that some programmer is going to make some really awful messy code for an AI to write clean code.

Robert Martin 37:21

And it doesn't matter if the AI writes clean code. No one's going to look at it, right? It's yeah, AI is gonna sit there and go and generate a whole bunch of code that no one will ever see, which is fine, fine, and then you look at the input, and the input is a horrible mess, because some programmer wrote a horrible mess on the input side. And all the same rules are going to apply on that input site's gonna have to be well organized, well described, because somebody else is going to have to maintain the damn thing.

Botond Seres 37:50

So we're kind of doing this already. So we'll look at all the high level languages like C# or Java, JavaScript, everything gets translated to some low level language, and we don't take a look at it, we don't care how it looks.

Robert Martin 38:05

Now generate JavaScript. JavaScript is the new binary.

Botond Seres 38:14

There's another thing like, as long as the client doesn't tell you exactly what they want, you won’t be safe. When was the last time a client told you exactly what they wanted?

Robert Martin 38:32

When the client writes the program, you say exactly what you want.

Dave Erickson 38:40

Well, it's kind of our job as developers to interpret, you know, what the client wants. And the first question, obviously, is, do you really want this? Of course, and why would you want this and then they can actually answer those questions. And you can say, Okay, this is how we might go about doing this, right. But yes, that is the most important thing. You know,

Robert Martin 39:02

I had a client once, you know, I was asking questions. I was doing all this stuff. They would say what the requirements were, I'd ask them more questions. And eventually, the client looked at me and said, You want me to do your job, don't you? I just need to know what to write here can’t you give me some details? No, it's your job to work out all the details. Don't bother me with all that detailed stuff. I'm a business guy. I don't need to, I don't need to think about that. Find what the tax rate is.

Dave Erickson 39:36

If I ever wanted to make a developer's joke book, I would just make a book full of SOWs.

Robert Martin 39:44

There are some good ones out there. Make it fast, make it easy. It must be easy to use.

Dave Erickson 39:56

Oh yeah, that's one of my favorites. Yes.

Botond Seres 40:00

One of my favorite guys was like, Hey, can you make this app? It's really simple. It should work exactly like Tick tock, but it needs to be more, by next week,

Robert Martin 40:12

but I have the idea. It's in my mind, I can see it. Yeah. Thanks. Thank you.

Dave Erickson 40:22

All right. Well, Bob, this has been wonderful. I don't know. Botond. Do you have any last questions?

Botond Seres 40:29

Okay, thank you very much, Bob. It's been great

Robert Martin

It’s been fun.

Dave Erickson 40:32

That's a good time. Bob. It's been really good. Thank you so much for your time. We really love this. But anyways, thank you so much. And to all of our listeners, until next month, this has been the ScreamingBox technology and business rundown podcast. Thank you very much for taking this journey with us. Join us for our next exciting exploration of technology and business in the first week of every month. Please help us by subscribing, liking and following us on whichever platform you're listening to or watching us on. We hope you enjoyed this podcast and please let us know any subjects or topics you'd like us to discuss in our next podcast by leaving a message for us in the comment sections or sending us a Twitter DM. Till next month. Please stay happy and healthy.

END