Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/coding culture: from nerd to necessary
38 Plays1 month ago
How did coding go from something niche and isolating to one of the most valuable skills in the modern workforce?
In this episode of Forward Slash, we look at how the role of the developer has evolved—from outsider status to essential strategist. Drawing on decades of experience, Mark Stahl shares how the culture around coding has changed, and why understanding systems, context, and collaboration now matters more than syntax. We also explore the often-overlooked power of clear requirements—how they bridge the gap between business needs and code, and why they’ll matter even more in an AI-driven future.
Recommended
Transcript
Misconceptions About Programming
00:00:02
Speaker
People are concerned only because they haven't spent a lot of time thinking about what programming actually is. And they conflate it with the mechanical act of just typing code into a on a keyboard.
00:00:14
Speaker
But that's really not what programming is. Programming is is the development of the recipe. It's not the actual cooking. It's actually putting together the right measurements four and the instructions and the steps of a given recipe.
00:00:26
Speaker
We've had junior level people look up to us before. We've been training junior level people before.
LLMs and Future IT Trends
00:00:32
Speaker
Our LLMs are effectively junior level developers. So I'm extremely
00:00:41
Speaker
Welcome to the Forward Slash podcast where we lean into the future of IT by inviting fellow thought leaders, innovators, and problem solvers to slash through its complexity.
Introducing Mark Stahl
00:00:51
Speaker
Today, we' going to talk with Mark Stahl. Welcome, Mark.
00:00:55
Speaker
Thank you. Thank you for having me. ah Mark has been writing code for over 30 years, 18 of those as a consultant helping teams solve hard problems across industries. He's worked with everyone from Eglin Air Force Base down in Florida, right, to Apple, doing everything from mission planning simulations to building toy interpreters just for fun.
00:01:17
Speaker
Mark's a generalist with a knack for translating fuzzy business goals into clear actionable steps for developers. Lately, he's been diving deep into developer tooling, making it easy for others to ship better software faster.
00:01:30
Speaker
love that. Better software faster. Okay. I have to ask about the, um, the, the toy interpreters just for fun.
Toy Interpreters and Influences
00:01:40
Speaker
That, that sounds adequately geeky. And I have to ask about that. Tell me a little bit about that.
00:01:45
Speaker
When I was finishing up my undergrad in computer science down here in Savannah, Georgia, i fell in love with Lisp and ah consumed basically everything I could about John McCarthy's work.
00:01:58
Speaker
And that led me to basically say, oh, it's not that hard to write an interpreter. So what like what do I want to write? I also liked small talk at the time. So I really was infatuated with syntax.
00:02:12
Speaker
I found the actor model with car hu Carl Hewitt's work. And so I said, oh, the small talk syntax and the actor model really line up well. And i so I dove into it and took about three months.
00:02:26
Speaker
I learned Go while I was writing it. So it was, which I don't recommend, by the way. I do not recommend learning a programming language while you're writing a programming language. It's a very bad idea. I'm learning a programming language to write a programming. Yeah, yeah. That would be a bit of a tall test. the The reason I chose Go, though, is because with the actor model, I needed concurrency primitives.
00:02:47
Speaker
And so instead of having to write those, I just chose a hosting language in order to to give me those for free, basically. I just had to manage the the channels in Go. So it was fun.
00:02:57
Speaker
It was fun, except for the recursive descent parsing. that was ah That was probably the hardest problem i ever solved. And then... it's just like any math falls apart. Once you figure out how to, uh, solve the equation and code comes out really easy.
Actor Model Explained
00:03:12
Speaker
Okay. So let's maybe do a crash course on the actor model real quick. What is the actor model? So imagine, that's your program is how we experience the postal system in the real world, except for packages are actually delivered.
00:03:27
Speaker
Um, so the, uh, The endpoints are named. So you have person A and person B, or we you and I right now, I'm person A, you're person B, and I say something to you and you hear it.
00:03:42
Speaker
So we have message passing going back and forth. and That's effectively the... um The gist of it, there is actually academic ah properties of the actor model that I don't remember off the top of my head.
00:03:55
Speaker
But that's what I was infatuated by, that it acted like the real world. We have this anon these anonymous, not anonymous, these named entities on either end. They hold their own internal state and they only access each other's state by sending messages back and forth.
00:04:11
Speaker
And I found that to be exceptionally interesting. Now, you were implementing the actor model.
Implementing Actor Model
00:04:18
Speaker
is was this to learn how to do it and learn it more deeply or or like, or you didn't want to learn Erlang?
00:04:25
Speaker
I didn't know of Erlang at the time. So this, so I i didn't know anything about it. um And i just also liked, i thought that the object oriented paradigm, the single dispatch of, of object orientation worked really well with the actor model, because when you have object dot method or object dot message, ah that ends up translating really well.
00:04:48
Speaker
to sending a message to, i mean, we see this with objective C, you send message to the object. So it was it was really just, can I do this? ah How does an interpreter actually work?
00:05:01
Speaker
um And then the bigger goals were, if this actually works, can we start to model, ah can we can we apply things that we know about the real world to writing software? Can I go to management theory books and start to apply those to writing software? And and the and the big picture, the bigger picture was during that period of time,
00:05:25
Speaker
the assistant, the the army had reached out to the software engineering institute at CMU and said, how do we manage projects that are a billion lines of code?
00:05:37
Speaker
And SEI said, we don't know. but what that's huge so let us do research and they came up with this book you can go look at it now it's called ultra large scale systems and uh they basically documented seven areas one of them was run times and i said that we we can't actually write a billion lines of code with the current paradigms we have so what paradigms do we know that we can use and the, and the, the, ah the longest running system is the universe.
00:06:09
Speaker
So let's start with what we know about some physics stuff and the actor model fit for that. Very cool. And it's not that we can't physically write that much code. It's that we can't have the code actually work when we're done writing that much. I would make the argument it's the it's our limitations of understanding that much complexity.
00:06:30
Speaker
and so So how do you manage our source code? All the tools that we have are not suitable for managing that level of complexity. Mm-hmm. Yeah, i first heard about the actor model we were doing. in I'm a Java guy, so ACA.
00:06:44
Speaker
Yep, yep. And Scala and all that. I thought it was pretty cool. One thing I really liked about it is like not only is the only way messaging, but it's it's kind of like a queue, right? So they only receive one message at a time so they can serialize the updates to their state so they can manage their own state very, yeah very concisely and they can control that very quickly. So I love that.
00:07:03
Speaker
thought that was really cool model. Yeah, it's really, there's it's interesting how many problems if you sit and think about it, that you can actually model using the actor model. You got to be creative sometimes and sometimes it doesn't work very well, but but there are a lot of applications that you, you know, once you dig in, you can really apply it.
00:07:19
Speaker
So pretty cool. The interesting contrast would be to today's ah concurrency primitives that we use, let's say specifically in Golang. i I was going to write a graduate school paper on this, but that that they're inverted. So the actor model has identity on either side of the anonymous communication channel and CSP or communicating sequential processes, which is what we have in Golang is the inverse of that. So we have anonymous endpoints.
00:07:47
Speaker
and then named identified means of communication in between them. That's also first class that you can pass around to functions and whatnot. So I thought it was very interesting that there's those two concepts seems to be opposites seem to be inversions of one another.
00:08:03
Speaker
All right.
Developer Tooling Focus
00:08:04
Speaker
Yeah. So you, uh, sounds like you do think deeply about, uh, developer productivity and stuff like that. Uh, I know in your bio, you mentioned that, you know, and in the latter part of your career, you've kind of gravitated towards develop, you know,
00:08:16
Speaker
helping other developers and and building developer tooling. Tell me a little bit about that journey. So that started with the language stuff. I realized that I was, i was I liked writing software purely because I liked solving business problems because at the end of the day, when I started, I graduated from high school, going into college. I did not want to be a nerd. I was a nerd my entire time at school.
00:08:36
Speaker
I did not want to continue on that. And this is before nerds were cool. um So this so was 1995. um And I wanted to do like a, it was a, it was a slur back then, right? Like now one hundred percent I'm a geek, you know, that it's cool now.
00:08:50
Speaker
yeah to be To like software at that period of time, you did not have a lot of friends. No, exactly. I went into business school first and focused there. That's what I did. and then But I was always writing software and for the job that i have I had just to make my job easier. to to which What technology is great at, it finding inefficiencies in whatever job that you have and optimizing those out.
00:09:20
Speaker
So all of it became tools. after After I got into the business of software, then it became, okay, how do we make this cheaper? How do we make this better quality? How do we make, and I spent my entire time in services.
00:09:34
Speaker
So where you have a time and materials contract, ah All the implementation is labor. And so let's see if we can optimize that to make our margins better. And that that was ended up being the focus, as well as the quality. We we are flawed individuals when rewrite software. and Tons of errors.
00:09:55
Speaker
And it's not just typing that helps us fix those things, but things like read eval print loops where we can prototype fast and we can figure out so what we're going to write before we actually write it and have the compiler scream at us. so it's it's just ah it's just a lot of interest in making more money really is what it boils down to ah by increasing efficiency.
00:10:16
Speaker
Very cool. Yeah. Yeah. I seem to have kind of gravitated towards that as as I aged up in my career. i Well, I don't know. I think I did it all along, really. um Early on my career, i I started working with like Apache Software Foundation and like building open source tools for other developers like Apache Commons and those sort of things.
00:10:34
Speaker
So I always kind of you know gravitated towards building tools for other developers. Not that I don't like writing actual like business software, but I don't know. I just found maybe like you that, don't know, that's ah that's a cool vibe to be able to help others do their job quicker and and faster and and you know more efficiently.
00:10:52
Speaker
I think there's something to be said for when you you need a certain amount of experience in order to acquire wisdom, in order to have taste. Actually to make good tools, right? Yeah.
00:11:03
Speaker
You can't just come out of the gate making tools. um you're yeah If you're doing that, you're doing them to solve your own problem, which you have to acknowledge that you have a problem, which means you have some wisdom at that period of time. So I think that it may be that as you get older, you focus a little bit more on tools because you actually understand what the problems are.
00:11:23
Speaker
And I know you mentioned you've been writing code for 30 years. I mean, you're younger than I am. So you don't, you don't look like someone that ah has been writing code for 30 years. but But like people ask me, like, when did you first start coding? way um I think i was like seven. So like I've seen the, pen my first program was like Atari joystick. Oh, sure. Button. Right. Like typing in basic programs. That was, oh gosh, hours and hours of that stuff.
00:11:47
Speaker
but But what about you? 30 years, you you would have been pretty young. So I'd been 15 and 47. um And that that wasn't the first program I typed in.
00:12:00
Speaker
i just, that's the first one I implemented. So the first one I typed in was, you remember that Apple twos came with a book with Apple basic and you could type in the programs in Apple basic to learn. i I don't consider that to be the start because I didn't write that code. I just copied what was ever in the book. I didn't understand what was going on.
00:12:18
Speaker
So in high school, I went to LaSalle. So ah in in your guys' neighborhood. And sophomore year, they had a basic class. you You had two computer programming courses. There was a basic. We used GW basic. So this is this is where we had to enter line numbers.
00:12:35
Speaker
And so you always did everything by 10 so that if you had to put a line in between, then you could do fives and then et cetera. So and then the the advanced course was Pascal. oh Oh, yeah.
00:12:46
Speaker
And I didn't end up taking the I didn't end up taking the more advanced course, oddly enough. But I stuck to basic and I ended up writing a ah menu system. um So it would drew an ASCII border around the screen, and then you had one, two, three, four, five in the middle, and then you'd press that, and it would go to a different menu.
00:13:04
Speaker
By the way, I did not know about finite state machines at that period of time, but that would have been a perfect use for us. So... That's cool, though. It jumped from there after high school to programming MUDs in college, so multi-user dungeons.
00:13:20
Speaker
um nice And depending on which type of MUD system you were on, you either had to program in C and then recompile the entire MUD and then there was downtime, or if you had something like LPC.
00:13:33
Speaker
ah which had an interpreted language so you could actually build while the game was running. um You could write monsters and everything. And it it had an interpreted language called LPC, which the modern implementation of that is a language called Pyke.
00:13:47
Speaker
Um, so it's, it's just a C scripting language basically. Um, so that was, that was the first experience mostly. It's so funny how many, you know, when we interview people to work at Caliberty, that's one of the things like, how did you get into programming? That's one of the things we asked people in the, well, always liked video games.
00:14:04
Speaker
It seems like that's, that is a big like avenue for people to get into our industry, which. I meet with my former dean of computer science almost every week. And and one of the big things that I see students now lacking and is that they don't actually know how a computer works prior to getting into the computer science department.
00:14:24
Speaker
and And I remember, is that like you we didn't have laptops with unibody cases and a single main board. ah You had to go build the machines and you had to figure all that stuff out. And there was a certain amount of... You had a certain amount of expertise because of that. right ah Now...
00:14:41
Speaker
i I don't even know. I don't know how these kids are doing it. How do you figure out what program you're going to write? um What's the, for I don't even know how that begins nowadays. It's very, but nonetheless, they should be building computers. That's what I tell everybody.
00:14:57
Speaker
Go, go out and buy pieces and build a computer. You need to understand how it all fits together. And nowadays it's like an art form too. Have you seen some of these rigs? these kids and These people are building these days. They're beautiful. I mean, I'm not fancy. You can see behind me. I'm not fancy at all. So i I don't get into that. i I'm ah purely pragmatic in that regard.
00:15:17
Speaker
But it would be, I mean, I've seen some of these videos of some of these builds and it's like these lights and side, side of the cases and clear and everything. Like it wasn't, wasn't, was like building PCs back, you know, when I was younger. So.
00:15:29
Speaker
Um, yeah, that's cool. Did you get, do you have to take like the, um, assembly language that we had, it wasn't just called assembly. It was like computer architecture and assembly or something like that. jump you that that That was, that was architecture. That was arc two is with a short hand name for that class.
00:15:43
Speaker
Arc one was, you know, doing adders with gates and whatnot. And I, by the way, I failed that class three times. Uh, really? Yeah, it was, terrible I'm terrible at the low level stuff. I'm absolutely terrible at it.
00:15:56
Speaker
Uh, when, when I got to arc two and I could do assembly language, I was okay. I understand registers. I understand the stack. I understand a program counter, all of that stuff. But the arc one terrible at the gates. I am absolutely like, like all the ants and oars and XOR gates and all that stuff. But I'm, I'm good at symbolic logic.
00:16:14
Speaker
I'm good at bullying algebra. I'm good at, you know, I can do all the truth tables. It was applying those things to the gates for some reason, just my mind did not rock it at all. It was very bizarre.
00:16:26
Speaker
So I won't mention names, but we had a professor. He taught the assembly. And assembly is kind of dry, right? I mean, it's not a like you're not excited by assembly language, right? It's not a real you know jump um out of your seat kind of a thing.
00:16:41
Speaker
But this guy was like the dude from Ferris buhler you know Bueller. He had like that monotone and just draw along. That's terrible. It was so bad. It was awful.
00:16:54
Speaker
and The guy was, he was fantastic. he was very knowledgeable, but he just had a way of talking that was, it was very much like, you know, Ferris Bueller's day off. That's what I thought of every time. And I'm like, just get me out of this class and let me just do the homework. Right. Sure. Yeah.
00:17:07
Speaker
One thing you mentioned, you didn't take any courses on like computer science history.
Learning from Computing History
00:17:12
Speaker
that And that was that was kind of an interesting thing that that I hadn't really necessarily thought about that because i I do that now. Like I read about those things now, but I didn't really have a lot of courses on the history of computer science. We'd get anecdotal things about...
00:17:26
Speaker
Euler cycles and stuff when we did the bridges of Konigsberg and in all of that, but like there's nothing going through the history of, of computing. So do you see that as a, as an issue in the industry today? what there's and There's a lack of it.
00:17:40
Speaker
Sure. because if If you, if you look at, I'll take, I'll pick on JavaScript developers here just because I spent the last decade ah being a JavaScript developer. So I'll pick on these guys.
00:17:51
Speaker
Um, Our industry is driven by fashion and you can actually see it's very prevalent right now with the AI hype that's going on. um So we are fashion oriented. It's always this is something new, et cetera, et cetera, et cetera. And and rarely are we saying, you know what, there's a ton of smart people behind us.
00:18:09
Speaker
We should probably go back and see what they were talking about and see if we can apply any of the skills two Because then we don't have, like, if developers were truly lazy, which we claim to be, that's why we write software, yeah then we would be going back and going, whose work can I steal and apply to my modern problems right now? But I think that the...
00:18:32
Speaker
the creative drive overrides the laziness. is So it is it is a desire to have an open source project and put your name on it say, I created that, even though it's the same thing that someone else did 10 years ago. oh so But i i didn't get into compute I didn't get into history in general until John McCarthy and and looking at Lisp and finding out that we had garbage collection in 1959.
00:18:59
Speaker
To where we had John McCarthy calling John Backus, the creator of Fortran and the creator of Backus Noir form, which is how we specify parsers, calling him and saying, hey, we did this cool thing in Lisp called a conditional. And I think it would be really useful for Fortran to have one as well. So we got if statements in 1959, 1960.
00:19:19
Speaker
um But I mean, there was there was obviously precedent for that in the the assembly side of things because you had jump if, yeah, jump if zero. um yeah So jump if false. Anyway. But that that led me to say, okay it's it's now 2002, 2003.
00:19:34
Speaker
two thousand two two thousand and three And here we go with garbage collection created in 1959. What else am i missing? um and so that that led me to Douglas Engelbart finding out about the the demo.
00:19:48
Speaker
um And you get to see the Stanford guy demoing the mouse um and a wimp interface and whatnot. And I'm like, holy crap, there's tons of smart people that we need to be pulling from. And that's usually my first avenue now is even with this AI stuff, I was like, all right, let's go back and check out what the AI winter people were doing at that period of time and and see, because we had Lisp machines and those machines have some of the best operating systems and the the some of the most efficient means to interact with the environment, the programming environment that I've ever seen.
00:20:20
Speaker
And so what can we learn and what's missing? Why aren't we doing that now? Those sorts of questions. I think I love that you like that. that Is it creative or or i don't know how you phrase it, but the drive like us developers.
00:20:35
Speaker
Okay, yes, I know that someone else in the ORM is the there's the classic one that people will do, right? Sure. Well, of course, there's ORMs out there and people have already done this before. I'm going to write my own. Everybody when you're 20 something, you're like, I'm going to write my own ORM for this project. because How could those people be smarter than me?
00:20:55
Speaker
why are we like that? i mean, I think it's, are we natural like problem solvers and kind of puzzled? You know, we'd like puzzles. So we want to figure things out and it's just stimulating to our brains. I don't know, but you're right. i mean, it'd be great if we could like,
00:21:09
Speaker
if we would streamline our the the evolution of computing so that we didn't have to kind of go back and relearn all these things again and go through the exact same problem over and over or cyclically like that. it's It's fascinating. I think there's a catch-22, and that is, for example, we don't know the recipe for Roman concrete, for example, right?
00:21:27
Speaker
So I think that the... Going back and recreating is actually a fundamental part of the creative process where that we kind of need to to. And how how do you learn? How do you more specifically, how do you know what you don't know if you haven't actually solved the problems? You don't know what they went through.
00:21:49
Speaker
ah how they failed, et cetera. So you go solve the problem. You're like, oh, that's why we don't do that. um Because that that's I ended up hitting this wall. So I think it's part of the creative process.
00:22:03
Speaker
But i I guess my issue with it is is that people don't acknowledge the past. If they came out and said, I'm doing this because I want to learn how these algorithms work, um And I want to know, nobody's documenting their failures in the code, right? They're documenting their successes because that is a working piece of code.
00:22:22
Speaker
So we don't actually know how they failed. And when you're learning something, failure is the best teacher um during that period of time. gets smacked in the face by the compiler. You get smacked in the face by your customer, et cetera, et cetera.
00:22:35
Speaker
and So I think it's important. I just wish people would acknowledge that. Hey, I learned this from this this paper, um or I didn't know about this until I listened to Carl Hewitt talk on a MSDN video about the actor model. And I said, to so it's really cool. So let's do this.
00:22:53
Speaker
Yeah. Well, I'm guilty of it. I mean, i was I'm taking a course on deep learning on Coursera and like, of course, TensorFlow and all those things are out there and I i could just use those libraries. But no, what do I do?
00:23:04
Speaker
I write on a library that builds neural networks. sure just just like i mean I literally did it to understand it. that's It's a learning tool for myself. But but i'm I'm sitting here like critiquing it. I'm thinking to myself, I'm doing the same darn thing. Exactly.
00:23:16
Speaker
And that's a learning process. You're not going to actually learn. And I'm sure we'll we'll get into this when we start talking about development with AI. But when I worked at a previous consulting company,
00:23:30
Speaker
One of my isms would be that the problem with developers is that that they like to write code. um So ah because we would have business cases that it would be good enough for the business case. And let's say that the the customer was happy with it, but the developer would be like, but no, it's not technically correct.
00:23:50
Speaker
ah We need to have it to be, it's it's it's it's not good enough. And I'm like, no, it is actually, because we need to move on to other things. So there, we do need those developers where they just like to write code.
00:24:04
Speaker
um And just writing code, I mean, you have to include, that includes re-implementing what's already been implemented. Lately, all the fad was single page apps. You're doing all of your rendering in the browser and all this stuff. And like, you know, they would be like, oh, that server side rendering you old folks do.
00:24:24
Speaker
That is so passe. What were you thinking back then? And now there's like, the we're coming back around to server side rendering again. And it's like, Yeah, I remember this. It's called CGI. Yeah. yeah For a decade, we listened to everybody telling us we were like old fogies because we, you know, servlets and JSPs and and and those sort of things like ah and and and mf MVC patterns and all that. Like server-side rendering was was bad and no, no, you need to be doing single-page apps. and And now we're coming back around to server-side rendering.
00:24:53
Speaker
Yeah. okay, fine. Well, I'm going to just dust off the old libraries. The PHP guys feel fully justified. say Oh, absolutely.
00:25:05
Speaker
They're like, nailed it you'll be back. You'll be back. Yeah, exactly.
00:25:11
Speaker
Unfortunately, they spent all those years trying trying to do the other stuff too, and they should have just stuck with what they were good at. Yes. Yeah, that's so silly. I think there's also, ah a touch on an interesting point there, there's also a a certain amount of religiosity that goes into where we're all in on a given technology.
00:25:30
Speaker
ah And that could just be human personality types ah where they get involved in the hype. I've never been, um not much of a, a team spirit sort of guy. So maybe I just have an immunity to to that sort of thing.
00:25:44
Speaker
i Because i don't I don't care about a given team. I don't care about a given any. So it's it's very interesting though, just to be all in on one given piece of technology, like single page apps are the future. this is not going to change. except Oh, wait, we're going to render stuff on the server as well.
00:26:02
Speaker
it Yeah, sometimes it works better when you do that. It's a little more secure um if you do that. Yeah.
00:26:12
Speaker
It's very funny. And I think there's a place for everything. I personally do like writing single page apps. I do like writing in react and those sorts of things. Um, but I, but there may be, you know, there's, there's a place for everything. So I, um, I usually do single page apps if I, if I have the choice because there's a level of complexity by adding a backend to the whole thing.
00:26:31
Speaker
I could just write in JavaScript. All the testing is very easy to do. Um, I, can deploy on Cloudflare, super simple, and just do refresh and everything just works and I don't have to set up a server. I mean, it's there's some niceties to it, but yeah, whatever. hits it's Welcome back to to what we did but in the past.
00:26:51
Speaker
So it, it and and we didn't really talk about like, you know, going down this path, but I would be interested to hear your opinion. There's in our industry for a long time, there was quite a, quite a bit of like pedigree ism, right? And everybody was like, Oh, were you, are you a Carnegie Mellon person? Are you, are you but a classically trained computer scientist and all that? And then, so they kind of overemphasize on that, but there's, you know,
00:27:14
Speaker
Lately with, I don't think we've ever had like a plethora of software engineers where we're like, man, what are we going to do with all these folks, right? That's never been the case. So the, you know, the boot camps have started coming out, right? So when you have 13, 15, learn to code and learn just to code and don't, you know, you don't learn the history of computer science. You don't learn all the ins and outs of all the things that we had to do, sorting algorithms and all that stuff. You don't learn any that stuff.
00:27:44
Speaker
But, you know, argument can be made. i don't really think about Big O, at least not consciously, on the job, writing business apps, right? i'm I'm, you know, just focused on a lot of the surface level stuff for the most part.
00:27:58
Speaker
What do you think about that? What do you think about that? Is is it is it okay? are they Is that going to work? I don't know. Where are you on that? So it's funny you say you don't think about Big I literally had a Big O conversation ah two days ago.
00:28:13
Speaker
About it solving a problem, and I'll tell you a little bit about, we have we're storing metadata on these entities in this application, and we're using Oracle 19c that doesn't have any ah JSON information.
00:28:29
Speaker
primitives in it. So there's just a blob in a column. And it's, okay, if I want to do a search, and let's say it's a Splunk style searching, so we, um or it just a space separated key value pair with an equal sign in the middle.
00:28:44
Speaker
Well, what do I have to do to find all of the entities that match that metadata. And it's like, well, I have to go find them all in the database. I have to unmarshall all the JSON for each of the metadata. Then I have to put them in a collection and I have to iterate over them, checking each key value pair. And that's O of at the very end, right?
00:29:04
Speaker
um And I was like, that's terrible. Because as this goes, we could have thousands of entities. And then each one of those could have hundreds of metadata fields. This is a problem.
00:29:17
Speaker
ah So i actually it's O of N squared because you have of N and then the entities and then you have the metadata inside itself. So I actually do think that that's a a, at least that the performance characteristics of a given algorithm.
00:29:34
Speaker
I think is important. And we, from the customer side of things, I could not change Oracle. I couldn't use something like Postgres where I could have Postgres optimize those JSON queries out.
00:29:46
Speaker
right and So we had to pull it into the backend as written in Go. We had to pull it into Go and and and do it that way. And so what we then have to do, if I was naive and I didn't necessarily understand the performance characteristics of a loop within a loop, then I wouldn't necessarily know, okay, well,
00:30:04
Speaker
We need to figure out how to assemble this ah into the storage trade-off as opposed to the CPU trade-off, which you wouldn't even necessarily know to talk in that language. Those the two trade-off characteristics if you didn't have, let's say, a data structures and algorithms class.
00:30:19
Speaker
um So I think that I'm not interested necessarily in having someone having a degree in computer science. I am interested in someone giving up free time to spend time on the thing they want to do for their career.
00:30:34
Speaker
So I think that that's the important thing is that you have to have the passion enough to give up other things, to spend time looking at these, let's say, performance characteristics. What's big O?
00:30:45
Speaker
Nobody ever talks about big theta or anything like that. So what's big O of of this? So I do think it's important, but I don't think pedigree is important. What we've found in our recruiting process, you know, and and as we you know hire developers, it's not really about what how many languages you put on your resume. that's It's not because of that. It's because of the the inquisitiveness and and the the yearning for that and for that learning, right? And the the the people who do...
00:31:13
Speaker
good, you know, tinker on the side, those, those sort of people that have that drive, the, problem solvers, the people who enjoy, who just love, they, can they sink their teeth into a problem. You know, those, those kinds of folks, those are the people that they'll figure out the language. They'll go learn, go, they'll go learn list. They'll know they'll figure it out in order to correct the problem.
00:31:31
Speaker
The problem is their drive and that, and the other things are just, they're just tools to get there. So that's been the thing that we, we seem to over index on. and And it seems like the, a better indicator for success.
00:31:44
Speaker
What I thought, when when was the learn to code thing? Was that 10 years ago? Sounds right. Something like that where we were telling miners like, no, stop mining and go learn to code.
00:31:56
Speaker
and it's and And then i had ah the problem I had with that was people, it made it sound like a lottery ticket. go Go take this boot camp, get a six-figure job, and everything will be great.
00:32:09
Speaker
Well, these guys, these people aren't going to get six figure jobs because they're, whether we like to admit it or not, our industry does command a given mindset ah to be good at it.
00:32:20
Speaker
And not everybody's going to be good at it. I am not the best developer in the world by any stretch of the imagination, um but I have social skills. So you're only allocated 10 points.
00:32:31
Speaker
That helps. That get puts you over the edge. ah You got to be a little crazy just to sit in front of a computer all day. you You do. You kind of have a little bit of something loose up there, I think. I think there's there's definitely a a type.
00:32:45
Speaker
um you Anybody can learn the syntax. I had a... Because I've always heard people say anybody can learn the code. Yeah, you're right. Anybody can learn the syntax. But I don't think people, you you have to like enjoy it to to stay, you know, deep down in the flow, right? With the with the you know the problem for sustained periods of time.
00:33:05
Speaker
If you don't enjoy it you aren't going to excel. mean, you can, again, you can learn the syntax, but you're not, you're not going to excel if you, if you can't stay down in the code or, you know, down in the problem like that. And you just have to enjoy it to do it.
00:33:17
Speaker
And where you must solve the problem. Yeah. You must, you can't, it's not, it's not a question of if you can solve it, you must. And I will not leave this chair until I've solved this problem.
00:33:31
Speaker
It's like an obsessive compulsive kind of thing. It's a a level of that. Absolutely. Absolutely. I had a philosophy professor. So that, by the way, I'm a big proponent of of of introducing at least intro to philosophy into any computer science program as well, because there's there's very programs that there's very few programs that have as much abstraction that computer science, which is a branch of mathematics ultimately. So math is is all about abstraction and philosophy is the other one that is really all about abstraction. And it's and it's really good because it teaches you how to ask good questions.
00:34:06
Speaker
You don't go, everybody thinks that philosophy class is about finding answers, it's not, it's about asking good questions. And that's really what you need to be able to do to be successful. in our field is you need to be able to abstract and you need to be able to ask the right questions to abstract.
00:34:22
Speaker
um But he was going to go into computer science um and he was doing his senior project and he went in to the lab at 7am and it was a Fortran project, 7am.
00:34:37
Speaker
And when he remembered being done, and was dark outside. And he said, i have to quit because if I don't, I will lose my life effectively because his life will be, he was so obsessive compulsive that he would just lose days.
00:34:54
Speaker
um And he was like, all right, I'm going into philosophy. that was his His father was the chair of of philosophy at Mercer. um so that So he had a pet he had background in that already, but he wanted to go into computers. so So it was interesting.
00:35:09
Speaker
So, you know, people like you and I have, or like you and me, have studied all this stuff for all these years. And then along came the LLMs.
00:35:19
Speaker
What do you think, man? What's what's going to happen to our industry? What's going to happen to people like us?
LLMs in Programming
00:35:25
Speaker
I was initially very bearish um because even at this current stage, it's a glorified autocomplete. Let's be realistic here. um i that's It turns out to be a really good autocomplete, but that's that's really what it is.
00:35:41
Speaker
so um And I said, you know, I've been doing this a long time. There's a lot of nuance and complexity in what we do. As I thought about it, so it's been been quite a few months that I've just spent thinking about it.
00:35:55
Speaker
now now i'm on the bullish side and i said yep i think this is again i made a comment earlier where technology is really good at finding inefficiencies in markets and and i'll use i'll use a very hyperbolic term eradicating those efficiencies with with extreme prejudice in many cases um and i think that's what we are right now people are concerned only because they haven't spent a lot of time i think thinking about what programming actually is, and they conflate it with the mechanical act of just typing code into a on a keyboard.
00:36:31
Speaker
But that's really not what programming is. um that Programming is is the development of the recipe. It's not the actual cooking. It's actually putting together the right measurements for and the instructions and the steps of a given recipe.
00:36:48
Speaker
So we see this, as you had said, we're both older. So we've had junior level people look up to us before. We've been training junior level people before. Our LLMs are effectively junior level developers.
00:37:01
Speaker
We have to tell them what the requirements are. We have to tell them not only what to implement, but to how to implement it. I need to tell you what file you're going to create. Here's the convention that we use at the company for naming our files.
00:37:15
Speaker
Oh, no, don't name the file the function that, name it this instead, because that's more clear. All of this is just like interacting with an LLM as far as writing software. So I think what, so I'm extremely excited. I think that at the end of of the day, we we will lose jobs. yeah But those jobs will be the individuals that we just talked about where are not really good at their job. They were the learn to code people that didn't really have a passion for doing it.
00:37:45
Speaker
um and And they're hiding amongst maybe large companies. um the The senior level people like myself, like you, there's it's more to programming than just typing on a keyboard.
00:38:00
Speaker
The problem solving that you do on a whiteboard, the design, the requirements, all of those things an LLM cannot do because it can't do creativity. But if you you pull that thread, you keep pulling that thread, it it gets really, can get really interesting. So prompting is kind of like what we've been calling all along in computer you know engineering or software engineering requirements, right? you're You're giving the LLM the requirements of what you want it to do and you have to get very explicit in order to get it to give you the right thing. is it is it Are we just entering into another world of like,
00:38:37
Speaker
where We have to be very good at requirements again and explicitly telling it and then the mechanics of yes keyboard keyboard keyboard and they'll let the machine do that part that we you know us us humans do now let it do that part but we still have to as you were saying get get down into the problem and understand the user and have the empathy for the user and what they're facing in their life and how do we how do we make that better is that kind of where we're headed.
00:39:01
Speaker
So first off, let's say that should be a happy future for us because that means I'm not going to have a massive case of arthritis when I get older in my wrists and my fingers, right? So I'm all about giving up the typing.
00:39:12
Speaker
um So, but yes, i think I think to put it from a, let's say a business perspective, I think the cost function for implementation will collapse to to close enough to zero to be effectively zero ah from a business perspective.
00:39:30
Speaker
what we will end up having to focus on. Because ah this is, this is i had spent a lot of time focusing on the requirement side of things. I'm going to name drop here. So the all in podcast, Chamath Pali Hapitiya had made a comment about the QA process.
00:39:49
Speaker
So this is, what's really nice about this is that it kind of bookends when I was looking at the requirement side. He had made, and this is ah a great point, that we went from a, we're going from a deterministic means of doing something, um writing this code this feedback loop to a probabilistic system.
00:40:08
Speaker
So I think in the four phases of software development, even whether we're talking about agile or anything else, we always have requirements, design, implementation, and test.
00:40:19
Speaker
Mm-hmm. that That was the case in the waterfall process. That's the case now with Agile. We just do it in a higher frequency. We're going to end up collapsing the implementation.
00:40:29
Speaker
And so we're going to have requirements designed because we're still going to have to figure out what the problem is. We're still going to have to try to figure out all right, what, let's say, patterns are we going to use to actually implement this software?
00:40:42
Speaker
We may not actually do the implementation. We just may communicate that via diagrams, via text requirements, et cetera, et cetera. But on the other side as well, because a computer, a machine, an LLM has no authority, we're going to have to QA it.
00:40:58
Speaker
And I think that will, that will when we say QA, we kind of think tests, whether those be unit tests, whether those be human test point and click, but I think it's also the peer review process, peer review process. So the LLM is gonna give us a diff of what it thinks it should change. And we're gonna go in and say, you know what, that's a bad name, let's change that name. And we're gonna be pointing at specific lines and saying, nope, we're gonna change that to this. This, again, going back to the junior developer comment, this is exactly the same thing that would happen.
00:41:30
Speaker
You're doing like a pull request for a kind of idea. Yeah, exactly. We're going to sit over the shoulder of, ah or or if we're in the same office, we're going to get together and we're going to go line by line. Nope, that's a bad change. Let's change this here. Oh, that's really good. I like this.
00:41:47
Speaker
Maybe we save that for later. um Where, no, let's not do that loop. Let's do a do while because we have to execute it at least once in order for... So those sorts of things, I think, are what developers are going to end up doing. So we're going to write the requirements of the design because they we need the brain of us to articulate how these things are going to be put together.
00:42:09
Speaker
The mechanical aspect of actually typing out code, again, it's a language model. of execute. That's going to be done by a machine. it's going be done really fast. But then we're going to have to come behind it and say, oh, that's garbage.
00:42:22
Speaker
um We're also going to probably have to go back and check our requirements because garbage in is going to be garbage out. ah So it's it's a it's a very interesting time that we're going to get into. And I think it's think it's going to be we're going to be able to pull from a lot of history and say 30 years of software engineering, of requirements engineering.
00:42:44
Speaker
We're going to be able to go back and and look through that and go, okay, how do we do this? How do we properly communicate to the LLM? I've been waiting for the right guest to have this conversation with. but So let's pull the thread further.
00:42:57
Speaker
Let's pull it. This is a little more. right Our sweater's not gone yet. Let's keep pulling this thread. ah Well, you said, oh, that's garbage. the The code is garbage. But what are how we've been trained through many, many years of of seeing good and bad code is is based on you know, a lot of a lot of it is about, is it readable?
00:43:17
Speaker
do When I look at it does it, is it doing kind of what I expect it to do, as Uncle Bob says? You know, good code is, when you look at it, it does what you'd expect it to do.
00:43:28
Speaker
But if if machines are editing the code themselves and and generating the code all the time, why does it matter? If a human being doesn't really need to to read it, why does it? Because does a concept of good code change?
00:43:43
Speaker
it I think ah when I'm speaking about it at this period of time, I'm looking only maybe ah six months to 18 months in the future. So i'm i'm I'm still a little bearish on the output of LLMs.
00:43:57
Speaker
So I imagine that I'm basically saying six to 18 months are still a lot of handholding. Human in the loop type. Yeah. That's right. That's exactly right. So, but as these LLMs get trained with better data and they end up becoming more efficient, I'm not sure that the quality of code is going to matter aside from the physical constraints that we have all the time, which is CPU, memory, et cetera, et cetera.
00:44:23
Speaker
Because now the question is going to be, The machine still has to read the code. It's effectively garbage in, garbage out. that's I still think there will be a concern for that. I still think, again, if for no other reason, computers do not have authority.
00:44:40
Speaker
so And we need to keep that always in in our mind, is that you are a machine. You do not have authority. You work under my purview. Right now we're talking about the output of of a machine's a machine of output.
00:44:55
Speaker
if you If you take the analogy of like business people today, but but like what what we have today, traditionally in in software engineering, business people say, i need a piece of software that does this.
00:45:06
Speaker
And they come to people like you and me or or a business analyst and yep and they say, okay, I'm listening to you. I'm hearing what you have to say. I'm interpreting your language and I'm saying, I think this is what this means.
00:45:17
Speaker
in some other language. we're We're a transpiler, so to speak, right? So I'm taking human language and I'm transpiling it into Java or Go or whatever. That's what we do. We we take the the place of the LLN. The language looks pretty foreign. to like if you ask the business person to read Go, there may be human yeah there' and English words in it, but they're not goingnna understand it very well.
00:45:41
Speaker
They may understand it to a degree, but not to the level that they would need to in order to work with it. What is this colon? Yeah. yeah what thing Why is it equals here and colon equals other places? That's that's still bugs me. with go Um, all right. So let's take that. Now the LLM is taking the, the, the, the part that we used to play of interpreting human beings say, I need this.
00:46:03
Speaker
LLM says, okay, I know how to translate that into something that a computer can understand. Well, it was a, it was a multi-step process before. So was human beings. to human being, this we would then interpret that and say, okay, we're writing source code, 3GL, those sort of things. But then we also had a compiler that would take that and turn it into machine.
00:46:22
Speaker
Why can't the, why not why not go away with programming languages altogether completely? they They can go away forever because why doesn't the machine just write machine code?
00:46:35
Speaker
It depends on what the training data Yeah, I mean, it it would have to be able to do that, obviously. But, like, there's really no need for human. If if we're going to turn turn it over to them, with there's no need for a language, of a human-readable language.
00:46:50
Speaker
No, it all just depends on the domain. So so that that would be the the the means in which I would pick a language. So if I'm writing for a browser, let's assume that WebAssembly is not ah ah prolific and ubiquitous amongst the browsers, then we're going to write in JavaScript.
00:47:08
Speaker
If I'm on the back end, now, now with the with the large language models, I will caveat this. I am not a typed language person. I'm actually a very dynamic language person because I have a certain amount of discipline.
00:47:23
Speaker
So I, I, I like the speed that I get with, and I hate a compiler yelling at me. So I'll get to it. ah Exactly. Like that was, that's my one big beef with TypeScript is that I like it.
00:47:37
Speaker
Thank you. But I'd really like to prototype this right now. So stop screaming at me that it doesn't, the types aren't there. It's really obnoxious. Do you remember the old, like, so you probably, so if you'd like small talk, visual age, remember those IDEs?
00:47:49
Speaker
yeah It would compile as you go and it would like complain at you. So you couldn't just like that flow with the code and type stuff. Anyway, that was an aside. I hated that. rick yeah Remind me ah to to to bring up a bring up the small talk reference of of of saving the image again because there's a good story. um So the I think that typing is actually going to be really important.
00:48:13
Speaker
from the LLM code generation perspective, only from the fact that it is a feedback mechanism to the LLM. So that, right. So it's like, I wrote this code and the compiler fails.
00:48:26
Speaker
I get feedback from it. It tells me what's wrong. And that feedback loop is, I think is exceptionally important, especially for reasoning models. So, that's The language itself doesn't matter, but I think the feedback loop matters more. Yeah, it was interesting. We had a client situation where we're speaking with client about a a problem.
00:48:45
Speaker
They have some software that's in ah and kind of an antiquated language, and there are people, not a lot of people, in existence that, that, you know, just on this earth that know that language anymore. Right.
00:48:59
Speaker
And sure. It was kind of mentioned like, well, now that we have these LLMs, well, why don't we just, instead of like, uh, translating that old language thing into ah modern day language and let's maintain that code. it was like, just leave it where it is.
00:49:14
Speaker
Let's just let the computers maintain it for us. we We're not really doing a whole ton of new features and stuff. We're, Why don't we just leave it where it is? the If the machines don't know how to understand and and edit the language, fine.
00:49:25
Speaker
we We come up with a situation where something breaks in the middle of the night. we We tell the machine the context. Hey, here's what the users are seeing, blah, blah, blah, blah. blah Oh, yeah, I'm looking at the code. i can The machine says, I know how to fix that. Boom, fixes It's done.
00:49:37
Speaker
What do we care? Interesting. It's an interesting idea. don't know if highly regulated environments would allow that, but...
00:49:46
Speaker
Sure. and And also how much of the training data has includes that language. yeah So that's, that would be the problem the obscure languages. Like let's say for example, I'm a huge common Lisp fan.
00:49:57
Speaker
Um, I'm probably not going to get very good output of an LLM in for common list, but because of this, not many people use it. I'm going to get great output for JavaScript. I'm going to get great output for Java. I'm going to get, and there's C C plus plus because there's nice code bases, actually very well written code bases that I can feed it in and say, here's what you should look at.
00:50:20
Speaker
So i I, think there's going to be some very interesting takes. I, I, I think there will be a lot of personal training for those things. I think we'll go away eventually, especially on the only speaking about the code generation stuff, we'll go away from the large language models.
00:50:36
Speaker
I think we'll get to the point to where we will have language specific. i can I can curate a list of projects. Maybe they're even internal to our own code base that I can feed and train as training data so that we can provide, let's say, company-specific context.
00:50:56
Speaker
um Or if it's a C output, maybe I go grab things like SQLite and really good, maybe zero MQ, really well-documented, really well-structured code bases, and I feed them into a system.
00:51:08
Speaker
And so I... increase the quality of my output. I don't know. I'm not, I'm not on the research side of things, but I think that that is a possible future with this sort of thing. What do you think about like um with these, you know, and not necessarily LLMs, but some, some of these models, these, these, we'll just call them AI models in general. Yeah.
00:51:29
Speaker
They're very big. They have a lot of parameters. It takes a lot of, yeah you know, if if you are training them, it takes a ton of time and a lot of money and a lot of compute. ah But also even on the inference side, once once you have trained it and you're ready for it to start doing things for you, that still requires so quite a bit of compute with, you know, you're transforming large matrices and all those things.
00:51:49
Speaker
Yeah. How are companies going to deal with that and, you know, are running all these things and and having to now understand this, this, you know, how to care and feed for these types of things. How are we going to deal with that?
00:52:03
Speaker
So I think, um, what in the prep call, I use the term fabulous, which requires some age, um, uh, to, to understand the context of what that even means. Maybe even it's a, so niche of a context, even some people where they're older won't understand it, but,
00:52:21
Speaker
In the the late 90s, mid two thousand s we had Intel, NVIDIA, AMD, et cetera. They all moved their manufacturing their chip manufacturing out as a core business. It was no longer a core business.
00:52:33
Speaker
They subbed it out. This is why we get TSMC, for example, in Taiwan. um So effectively, Intel, NVIDIA, AMD, they're all design houses.
00:52:44
Speaker
They really just design the chips and then send them off to a fab to be manufactured. Okay. I imagine, and we kind of have that for hosting of services now. We have AWS, we have GCP, we have Azure.
00:52:59
Speaker
ah Before that we had colos and we had VPSs, um virtual private servers. I imagine the same thing's gonna happen. The capital expenditures that are gonna be required to, whether that be from a power perspective, whether that be from a cooling perspective, whether that be from a GPU perspective,
00:53:17
Speaker
they're they're not Not a lot of companies are going to be able to suffer that. um So I think that there are business opportunities for VPSs for models to where they can offer me compute. I can go in and train them. I may have people on staff that know how to train models, just like I have people on staff that know how to write software.
00:53:37
Speaker
ah Or I may come to a third party, a consultant, say, i I need this stuff
AI Model Hosting and Training
00:53:43
Speaker
done. And that consultant says, we have a great model for TypeScript. That's going to generate amazing code and therefore that's going to decrease the cost of implementation.
00:53:51
Speaker
I don't think everybody's going to have necessarily a model. Um, Or if they do, they don't care about the time it takes to generate code. So you think so I could see. Yeah, the like the economies of scale. little Just the reason AWS is successful is because they can put 500 people's data center in one building with one cooling system and one, you know, in pipes in and out and all that stuff. Redundant power, as you were saying. and So those economies of scale, same thing, but just for model hosting. So instead of.
00:54:20
Speaker
You know, yeah business workloads, it's AI workloads that are being. It's just compute. why is it any different than than a Lambda function? Yeah. Right. It's, it's data in and it's data out. There's not, there's not much difference.
00:54:32
Speaker
So, so it's, um, I, I could see as well though, uh, to, to create an XKCD comic where, where life imitates art and art imitates life. I could see that I could see that me having a model on my machine, maybe hosted in a Docker container that, uh,
00:54:51
Speaker
I'm typing out requirements and I'm typing out design and I push enter and I go walk away and make lunch. And this used to be our reality in, in nineties and early two thousands, right? This yeah writing in C++ plus plus and then we'd hit compile and be like, all right, I'll wait for that to fail. Time for lunch, um at coffee, got some laundry I got to do. Yeah.
00:55:11
Speaker
And, and for the listeners, the references, the XKCD comic where code is compiling, go look it up if you don't know what I'm talking about, but it's, it's two developers sword fighting is on the back of chairs. Um, And the manager yells at them and said, are guys doing? don't you back to work? And code's compiling. And that that used to be our reality. Yeah. Oh, absolutely.
00:55:27
Speaker
Yeah. We didn't have like three second come you know build times and back in the day. was hours and hours. That's even long. yeah That's long. Three seconds is a long time. Yeah. Well, I mean, like with tests and everything, like full full test cycle, build, compile, all that stuff.
00:55:43
Speaker
ah how like We can be in production in three seconds with some things. Yeah. I'm so spoiled that I get so angry with, with CI running. Cause I, I, I'm like, this takes way too long. is this takes so well I'm such a geek. I started like, like for my, for my side projects, I, you know, I, I run them on GitHub as GitHub actions, all my, all my builds and everything, but like the, it doesn't really run there. I have a little Linux server at my house and I'm like, this, this is my runner. Cause I get so sick of like the, they're, they're not as fast. And I'm like three times as fast running out of my, just my little Linux server that's here at my house. It is like so much faster.
00:56:20
Speaker
patient time is money yeah time is money yeah this has been awesome but we're going to move on to ship it or skip it and i think we can probably get into into some interesting topics and ship it or ski it that we kind of touch and some she ski but ships give everybody we got to tell if shebos good What about killing the keyboard voice based coding? And then what I thought of when I was thinking about this was like Jarvis, you know, I always, I bring this up a lot to people who listen to the show here. i've I've mentioned the Jarvis thing a lot of times, but like, you know, Iron Man's like, Hey Jarvis, blah, blah, blah, blah. Oh yes.
00:56:53
Speaker
Putting that together for you now. So, you know, like, sure. Will we be doing that? Like right now we're typing into a keyboard, even with LLMs we're typing most of the time. I do interact via voice, what what do you think? I think that's how how we're going to code in the future.
00:57:06
Speaker
I think that we will articulate voice for requirements design. i do not think we will articulate source code via voice. ah So we will articulate, here's the functionality I want you to build and here's how I want you to build it.
00:57:22
Speaker
And then you will ask me any questions if you need further clarification, but I don't think we'll be like, if open parentheses, blah, blah, blah. Yeah, I don't think of them mc mechanically, no, you know. That would be but so terrible. But do you can say like, iterate over these things and just give me the first name of all these objects.
00:57:38
Speaker
you could Yeah, sure. And generate that. you can Yeah, i think I think that that's completely possible. I have a little app I wrote for myself. So when I'm out walking the dog, I can make a phone call. um The service picks up on Twilio and I just start talking. It tells me to start talking and I'll use this as a brainstorming session. And then when I hang up the phone call,
00:57:59
Speaker
It will get transcribed. It will get summarized. And then I'll get any action items coming out of it as well. And then that will get texted to me with a URL that I can open up. and i can And so I'm most likely going to add that to where it'll email a certain email.
00:58:15
Speaker
So it'll go to make.com, for example. And then I can extract all of that information and maybe turn it into, you know, summarize this, reorganize it to because my thoughts are a little bit all over the place sometimes, reorganize this into a blog post and email it to me again.
00:58:31
Speaker
And so that I have content. I talked through all of this stuff. Now I have content to go in and fill out, but I don't have a blank page. um The phone thing was important for me using the phone because I don't like apps. I don't want to develop an app.
00:58:45
Speaker
I don't want an app on my phone. So just making a phone call ah was super useful for me. I love it Musings with Maisie. Blog posts from walking my dog. I don't know what your dog's name is, but I just made that up.
00:58:58
Speaker
That's cool. All right. So his name is Whistle. Whistle. Okay. ah Whistle. ah What is it? Whimsies with with whistle. I don't know. um I'll figure but I'll come up with something better for you. yeah but if you're Whimsical ways with whistle. yeah All right so So voice-based coding, you're a skip it or probably coding, skip it, but...
00:59:22
Speaker
i think I think coding is the wrong word. yeah I think i we already know transcribing. I say ship it. We're going to end up articulating requirements and design via voice.
00:59:32
Speaker
Okay. And I had this idea. didn't really pick, I didn't get this from anywhere, but it it kind of came to me as I was like researching for ship it or skip it. So what about like, what if you use AI to to kind of AI driven TDD test driven design, right? So what if the, the AI does the, the testing upfront and then that's almost like a context for itself. Like, okay, we, we hone into all the case, the, the cases, the edge cases that, that,
01:00:03
Speaker
need to be covered and all of that sort of stuff. And then the AI generates a test case. Now it's the context of like, okay, feels like a good test suite covers all the cases, go make the code that makes it this green. so So again, this is another one of those nuanced things. I think it's the the wrong question.
01:00:20
Speaker
um I'm not a big fan of test-driven development because at the end of the day, my tests should cover the requirements, not cover the code, so to speak. So I would say, i would say,
01:00:32
Speaker
um writing to the requirement and getting a constant feedback of failing. So as it's writing the the algorithm, it's also writing the test. But at the end of the day, to meet the requirement, not necessarily to get a green light.
01:00:45
Speaker
on because that's the TDD thing, right? Is it, I'm going to write just to the algorithm that I'm doing. So I would say, yes, write the test to beat the requirement that I give it. um Not necessarily to meet the structure of the code, because I, I believe that's a fruit of the poison tree. Basically we're writing to the thing that could be broken as opposed to writing to what I'm trying to implement.
01:01:10
Speaker
It's like the wrong premise. I think it's the wrong premise. Yeah. So this one's kind of related. i was thinking about this and i and I think we briefly touched on this in the prep call for this this episode, but um could IDEs, like our integrated development environments, what we, you know, the things we hold near and dear to our hearts, you know, every day we live and breathe in these things.
01:01:30
Speaker
are they going to evolve to be more about honing requirements over time? And then just like what we were talking about the mechanics of, you know, spitting things out. Like, is it, are we going back to rational rows? You know what mean? Like, no is that, no is that the, are there, are our IDEs really going to be about, here's the problem. Here's what I'm trying to do. Here's the, here's the requirements of the situation.
01:01:53
Speaker
And then the ID helps me hone that. And I work on that. And then the output is just the code. I, and I'm actually working on a project related to this.
Future of Requirements Engineering
01:02:03
Speaker
i I don't necessarily call them IDEs, but requirements elicitation tools are are going to come make a comeback. And Rational Rose, that you make a mention of it, that was a diagramming tool but ah that IBM purchased when they purchased Rational software. and And they subsequently purchased Doors, which is the big requirements thing. And that's now under the Rational banner.
01:02:25
Speaker
um Everybody hates it. So I'd love to compete with them. ah So it's, i think that, so here's a problem. that I'll articulate. So I watched a video from the VS Code channel, and this was talking about the new changes they've made to co-pilot.
01:02:42
Speaker
And the guy's going through and he gets to PRD, product requirements document. And my interest was piqued and I was like, okay, let's see what this... So ah he he basically said, this is a product requirements document. Here's the requirements and then moves on. like there is no There was no conversation about what this is.
01:02:59
Speaker
One thing I noticed was it was a markdown file with a single with a table, four columns, I believe, and all of the IDs were just sequential. So one, two, three, four, five, six, seven, eight nine.
01:03:12
Speaker
I said, okay, that's fine for a trivial project. What happens when that becomes a non-trivial project? Are you going to have thousands of requirements? So it's going be one, two,
01:03:26
Speaker
1,897 is what how do you organize this requirement? How do you organize these things? So I think this is what the problem is going to end up being. We will use requirements to communicate to LLMs and then we will say, just like we did with source control, by the way, this is why we don't sneakernet our patches back and forth.
01:03:44
Speaker
I haven't heard that one in a while, but for those of you uninitiated, sneaker net is where you you, know, you pick something up on it, like of a thumb drive or a, or a disc back in the day, a little floppy disc and you walk it over to where it needs to go instead of, you know, That's that's exactly right. but Or, heaven forbid, ah Linus receiving patches via email and applying them to the Linux kernel, right?
01:04:08
Speaker
So God forbid we have that again. but That is terrible. um So we're going to have the same thing with requirements if we're going to have the same thing with prompts. um So how do you manage when you when you start doing this at such a large scale?
01:04:24
Speaker
Right now we're doing it at these trivial BS apps that have like a handful of requirements. That is not how the real world works. ah So I think what's going to be really interesting is we're hopefully going to go back and we're going to pull from 30 years of software engineering experience and we're going to go oh my gosh, there was an entire field called requirements engineering.
01:04:46
Speaker
That is basically prompt. Prompt engineering, yeah. um And because once again, the reason it's called prompt engineering is as we started off this conversation, we like to build things and we're going to just, oh my gosh, we have to be specific about stuff that we write to the computer. And we're going to call it prompt engineering. You know, that's, we've done that already. we We're past that point with requirements.
01:05:07
Speaker
Yeah. So why are people... So, okay, I'm going get up on my soapbox. Why are people okay with, oh, we have to teach ourselves prompt engineering. We have to get so much better about and telling these things to to the to these computers.
01:05:22
Speaker
When us poor software engineers for decades have been saying, no, no, you can't just say, build me a checkout system. Tell me a little bit more about what you need. And they would throw their arms in there and get upset about that when a human asks for clarity. But now that a computer is like...
01:05:35
Speaker
oh, here you go. And it goes the wrong thing. They're like, oh no, I need to learn. I i need to do better. Why is it that they're they're willing to go the extra mile for a computer, but they weren't for us for decades?
01:05:47
Speaker
that Because they don't understand the connection. By the very nature that we have people talking about being specific in our English, they don't relate that to the fact of why we have this arcane syntax in our programming languages.
01:06:00
Speaker
It's the same reason. yeah It's because computers are morons. And we need to be very specific. Going back to the peanut butter and jelly sandwich example, by the way, for the audience, go look up the, I don't remember what the title of the whole thing is, but there is ah peanut butter and jelly specific requirements ah thing. And it's terrible. It's terrible to read. And this is what our future is going to look like for a little bit. They're they're not relating what they do on the day-to-day to now this English abstraction. Yeah.
01:06:32
Speaker
And I think that that's really the problem. we We have to be specific, which is why we have computer programming language and the comp computere and the computer programming language history is all about increasing the abstractions.
01:06:45
Speaker
We went from... flipping switches to machine code, to assembly language, to 3GL, and then finally 4GL. I mean, COBOL and SQL were meant to be used for business people.
01:07:01
Speaker
Don't forget punch cards. Oh, yeah, I forgot. I did forget punch cards. That's right. You forgot the punch cards. this is just another abstraction.
01:07:11
Speaker
Yeah, absolutely. So requirements-based IDs, I think that is something. I think that's going to be a a ship. it i'm i'm i like I think there's there's a there there when it comes to like we're going to be spending an inordinate amount of time honing and refining requirements with these, even with these LLMs, that's going to be the, a big bulk of our activity going forward is making sure that the requirements are, are sound and edge cases are covered and whatnot.
01:07:37
Speaker
i think there's ah I think there's a bigger question in there, and that is we've known about requirements for such a long time. Why do we not do them now? Right? we Yeah. And because we we know, if I go to any programmer right now, and let's say this guy is ah is an agile zealot, and I go to him and I say,
01:07:58
Speaker
build me a checkout system. And he's going to get he's going to start asking me for requirements. Yeah. He can't just build, but he's, but I think there's this connection between requirements and the waterfall process. The R word is a bad word.
01:08:11
Speaker
Yeah. Yeah. We also developers are not known for writing documentation. news And so ah subsequently, I think that requirements end up being this nasty form of documentation because it requires you to sit down and think about the domain And we've been told for such a long time that, well, you can't know all the requirements up front.
01:08:35
Speaker
And coming from the defense world, I can assure you that you can you know all the requirements up front, given you have to be a little bit flexible during the the project process.
01:08:48
Speaker
But you can get the big picture requirements yeah very easily in the in the beginning. it's It's very interesting to me what I think the future holds for software development. I think it will add a level of professionalism that I think that we currently lack.
01:09:01
Speaker
Because I do think that the the industry is is very unprofessional in how it approaches its ah production, it's product production. It's output.
01:09:13
Speaker
Yeah. I mean, I can see why engineers, you know, they kind of turn their nose that when we call ourselves software engineers, they're like, right. Come on now. If I do my job wrong, engineer, engineer, and a bridge falls down, you know what I mean? like So I have to have a level of rigor. It is built into my practice in that now. I'm trained.
01:09:32
Speaker
We don't, as you're saying, we don't have that level of professionalism or rigor in what we do. We're very sloppy in comparison. So probably shouldn't call ourselves engineers. I mean, even though I do, I mean, I'm not sloppy. Of course not.
01:09:45
Speaker
I rolled my eyes by the way. I still at this, I call myself, I used to call myself a software engineer. I call myself a developer at this period of time because I don't, my job does not command the level of engineering I used to have to do. I don't have to write software requirements, specification anymore or software design document.
01:10:04
Speaker
Those aren't required for the contracts anymore. I thought we were going to talk about vibe coding. Oh yeah. well You're going to ask me about that one. I mean, we can, you want to do vibe coding? I have very, a very simple quip. I don't vibe code. I'm a professional. profession Yeah. So I don't vibe code.
01:10:19
Speaker
Okay. So you're a skip it then. Yeah. I'm a skip You're skip it. I think any, it's interesting when people talk with like vibe coding, like I think anytime you kind of interact with an LLM and and spits out any level of code, I mean, that's technically vibe coding. I don't necessarily hate the idea, especially if you're,
01:10:38
Speaker
If you're just saying, I'm going to say some stuff and take the code that it spits out verbatim and there's a run with it, you know, YOLO it to prod. If that's what your vibe coding is, and then I'm going skip it, skip it, skip it. But I do think iterative working, like it it was very helpful for me when I was writing my um my my side project, my library for doing neural networks.
01:10:56
Speaker
It was very helpful to kind of go back and forth on ideas and say, well what do you think about this code? Oh, I think. you know It is helpful in that way. but But as far as like just spit out the entire project and i'm just going to YOLO that to prod, I don't i don't think that's good. that's And that's when I'm on X or whatnot looking at the people talking about Vibe Coding, that's what they're talking about, right? is that i entered in ah Or if you go look at the companies like Lovable being a specific example, V0, they just want you to enter in a paragraph. Right.
01:11:25
Speaker
And then they just accept like what comes out. That's terrible. yeah Absolutely terrible. but yeah ah It's funny, maybe we'll we'll accelerate the movie Idiocracy in the software development world faster than the greater population.
01:11:40
Speaker
I am very much the get off my lawn sort of side of things on that. Like I am that old that nope. I don't want any part of that. All right. So you're skip it. I'm skip it. Like the YOLO to prod level vibe coding. I'm scared as well, but I, but I do find helpful.
01:11:58
Speaker
I do find it helpful to, to leverage LLMs to, to help you know mold ideas over time. It's it's kind of a good like pair programmer almost, right? Like a rubber ducking. I've used it to find requirements that I didn't specify.
01:12:11
Speaker
Yeah. What am I missing? Yep.
Lightning Round Introduction
01:12:14
Speaker
Yep. yeah That's a great prompt. All right. On to our most important segment of the show, the lightning round. time for the lightning
01:12:31
Speaker
Rapid fire, don't slow down. Hands up quick and make it count. In this game, there's no way out. It's time for the lightning round. All right. So this is the idea here is we will give you some very important questions. These are like make or break questions for the the entire episode. Like the the answers to these will will make or break the success of this episode for you, not me.
01:12:56
Speaker
I will be determined to be a moron or a genius based on these correct questions. Yeah. Yeah. Can I just hedge my bet and say I'm a moron and be a... You can. Yeah. so you're you're shorting yourself there. as what good yeah That's 100%. All right. So they end the answers to these, so they're they're very heavy.
01:13:14
Speaker
The answers matter. So you really don't want to just blurt out an answer. You want to put a little bit of thought to it. um Because it's it it does. mean we We're scoring. you know There's a whole process here.
01:13:26
Speaker
All right. All right. Okay. So let's get into it. The real meaty part of this show.
Lightning Round Questions
01:13:32
Speaker
Name one of the seven dwarves. Sleepy. Sleepy. We would have accepted any of the other six as well.
01:13:40
Speaker
What's your favorite carb? Bread, pasta, rice, or potatoes? Bread. Now, again, don't feel like you to alert. It's butter delivery mechanism, by the way. Butter delivery. Yeah. that's all That's all bread is. is's It's for butter delivery.
01:13:53
Speaker
That's what I call carrots is my hummus delivery system. that sure That's exactly right.
01:13:59
Speaker
If you were given an all expenses paid trip to Cleveland, would you take it No, because I'm from Cincinnati and we don't go to the armpit of the Midwest. Amen.
01:14:10
Speaker
Amen. That's, that's actually what I had written down as this is the acceptable answer. that you Verbatim. You nailed it. That's perfect.
01:14:19
Speaker
If there's a spider in your house, do you kill it or set it free? It depends on how close to the door it is. I think it depends on how much it surprises me. Like ah if if it angers me, but for the most part, I'll, I'll let them free. Yeah.
01:14:36
Speaker
It's getting the boot. Yeah. Uh, what's your favorite clothing brand? Whatever target sells, whatever target sells. Okay. Yeah. I don't really look at the the brands.
01:14:49
Speaker
If it feels good, I and then look at the brand and then I go buy more of that. How long can you hold your breath? Oh, I haven't done that in a while. Uh, probably 90 seconds.
01:15:00
Speaker
It's not bad. That is above average. I believe the average is 72.6 seconds. And again, I made that up. Okay. Yeah, but it sounded good at the time.
01:15:11
Speaker
Say a word in Spanish. Hola. Yeah.
01:15:19
Speaker
Favorite junk food? Cereal. Cereal? You can consider that a junk food? but Now, what kind cereal are talking here? Golden Grahams, Frosted Mini Wheats. um What else?
01:15:31
Speaker
ah Cracklin' Oat Bran. Oh, Raisin Bran, but Kellogg's, not the Post, yeah or Kroger. ah But you gotta have the two scoops um because it's sweeter. those are that's That's my guilty pleasure is cereal.
01:15:45
Speaker
That's I've been doing this. I want raisin bran crunch kick. Oh yeah. I don't do the, I got the, I got the crunch. That's what I've been doing lately. Favorite city in the United States besides the one you live in.
01:15:58
Speaker
Key West. Probably. I used to live in big pine key. I worked for the boy Scouts. Uh, that down there. Nice. So Key West is really nice. Invisibility or super strength.
01:16:11
Speaker
Hmm. Can have both? Can have both? I mean, yeah. Okay. I don't actually know. and don't know the I mean, i think in this world, if you if you have one, i would see it.
01:16:25
Speaker
It shouldn't be that hard to have the other. You can already have one of them. like that you know what I mean? Like if we're already going to this level of certainty, yeah, let have whatever you want, right? You can have laser eyes for all I care. I would prefer speed, but i'll I would probably take the strength. Yeah, the speed is, I find the flash to be very interesting. I think that's think that's all of our of our questions. So anything like closing You guys got to bring harder ones.
01:16:48
Speaker
Yeah. And they're they're very important, right? So any closing remarks, anything to add, you know, kind of, you know, things you'd like to opine about and share with the folks?
Promoting Requirements Engineering
01:17:00
Speaker
Yeah, I think that anybody who's listening, I recommend going back and looking requirements engineering. yeah i think i Start getting good at being able to write requirements.
01:17:11
Speaker
RFC 2119. The musts and the shall. Yep. ye Anything you're promoting? Anything like you have to do side projects that you tell people yeah So right now I'm working on a requirements management system that's specifically going to tie into i'm goingnna tie into LLM. So actually right before, a couple days before this podcast, I got the where I was happy with the minimum viable product.
01:17:39
Speaker
have I've wrote written a terminal ah project management or not project requirements management system. And so the idea there is going to be traceability. So that's the big thing, everyone listeners, the big thing is traceability. Like provenance of where, where did you get the idea to make this software do this and it and here where in the requirements, like where did it come from? Is that the idea? All the way down to a given test case, all the way down to a given line of code. We should be able to, and and I would make the argument that if we can do it in the technical realm, we can go all the way to business as well, because we're writing software, not because the bosses like it, but because it meets a business goal.
01:18:16
Speaker
Well, what's that business requirement? Somebody's got OKR that they said, hey, we need some software to help me make my OKR, right? And it's measurable. So the
Show Wrap-up and Credits
01:18:24
Speaker
the question begin the the question starts to be is, can we apply requirements to business as well?
01:18:29
Speaker
And so and and what how do we measure that? How do we test that? Et cetera, et cetera. Well, this has been awesome. you know Thank you so much for joining us today. This has been really great.
01:18:43
Speaker
Really appreciate having you on and Mark Stahl. thanks for having me. I appreciate it. If you, uh, if anybody wants to reach out to me, X MJ stall zero, um, and then, uh, Mark at technically correct.com.
01:19:01
Speaker
Um, that's the, the company that will be choosing the product. So you can reach out via email and then 1 million monkeys, 1 million monkeys.substack.com. All right. Well, this has been the forward slash. If you'd like to get in touch with us, drop us a line at the forward slash at Caliberty.com. That's C-A-L-L-I-B-R-I-T-Y.com.
01:19:20
Speaker
See you next time. The forward slash podcast is created by Caliberty. Our director is Dylan Quartz, producer Ryan Wilson, with editing by John Corey and Jeremy Brown. Marketing support comes from Taylor Blessing.
01:19:32
Speaker
I'm your host, James Carmen, and thank you for listening.