A lot goes into writing an application that knocks it out of the park. One of the ways to look at the different components of success is to view programming as a story with three layers. In this episode, we dive into these separate, but very interlinked aspects that go into the storytelling of programming. We kick off the show with a look at the first layer, which is the story you, as a developer, tell the computer. We explore both how it can go right and so very, very wrong. From there we look at the second story, the one you tell other developers or your future self. It’s important to remember programming is a team sport, so tell your story with this in mind. The third and final story is up next, where we look at the user experience and what we can learn from it. We round the show off with Mike’s reflections on a past project, and how the three elements of storytelling panned out. If you have any of your own experiences with programming as storytelling, share them with us! Be sure to tune in today.
Key Points From This Episode:
Transcript for Episode 160. Programming as a Story: How we tell three different stories when developing apps
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host today –
[0:00:09.5] DA: Dave Anderson. Right by the Jersey turnpike.
[0:00:12.9] MN: Hey, awesome. Today, we’ll be talking about programming as a story.
[0:00:20.8] DA: Let me tell you a story Mike. I got a story for you.
[0:00:23.6] MN: I’m all ears. What’s up?
[0:00:25.6] DA: Sometimes it goes amazing and sometimes it goes pretty badly. Actually, it’s three stories in one. It’s like a Rubik’s cube of stories.
[0:00:36.9] MN: Yeah, I think you had mentioned earlier about all these different stories that happen in the daily life of a programmer. And I thought it was very interesting, enough for us to talk about it. And I do for some strange reason have the thought of like, “Every developer is like their own personal Stephen King if you will,” but not as amazing as Stephen King. That guy’s amazing.
[0:01:04.0] DA: Man, hopefully less drugs and coffee. Well, just as much coffee.
[0:01:12.2] MN: Less fear and clowns and your writing of these stories. Yes.
[0:01:18.0] DA: Unless you’re debugging, then maybe –
[0:01:21.5] MN: A lot of screaming and debugging for me for sure.
[0:01:25.1] DA: Yeah, I had this thought the other day – There’s different ways to look at programming like there’s like the aspect where you're talking to the computer or to another programmer or like to the user and all these three things are different kinds of stories. And I came across this great article by David Hayes from Press Up, from a couple of years back that really like articulated what I was thinking about and I kind of love it.
It’s kind of different lenses that you can view the work at and if you succeed in one, it doesn’t necessarily mean that you're going to have a successful long-term future. You got to get it right with all three in order to really hit it out of the park with an application.
[0:02:11.5] MN: Yeah, we could just dive right into these three different types of stories that programmers tell and what – when it goes right and when it goes wrong and how to prevent those things from going wrong and make it sure that they’re going right.
[0:02:26.8] DA: It’s got to go right.
[0:02:28.9] MN: It has to. It’s part of our job is to make sure it goes right. I want to start at the very bottom, I’m calling it the bottom layer because it’s the one the most closest to the machine and the computer and it’s the story you tell the computer about how to do a specific task.
[0:02:49.1] DA: Right, yeah. You have to write code and the computer takes that code and turns it into something that tells a computer what to do. Put the variable here, do a loop, call a method. You know, if it works, then the computer works, that’s it. You’ve succeeded.
[0:03:14.3] MN: The way that you would make sure that it works, you know, every programming language is different so you have to know the correct syntax and the correct way to write a for loop, right? And if else statement looks completely different in JavaScript than it does in Ruby. They’re similar concepts but the way you write them are different and the computer needs to know how to translate this piece of code depending on how you write it given the programming language that you're in.
[0:03:44.3] DA: Right, yeah. The earliest way that you can screw that up is like if there’s like a typo or like some syntax error in the code and doesn’t even compile, doesn’t even run. But more subtly, if you get it wrong then there could be a bug in there. It could go wrong in production and have an issue for you or user.
[0:04:09.0] MN: Right, the idea of writing to the computer is a story that we’re constantly battling and to ensure that we’re doing it correctly so that we don’t get those compilation errors or miss those semicolons or what have you.
[0:04:23.5] DA: Yeah, we talk about like unit testing and integration testing and all that all the time as like, a way to maintain correctness of a program. So, yeah, that’s the tool that you can use to make sure that things still work as you make changes to the program. You're not breaking that first story of correctness.
But even that’s not really enough because after you write the code, inevitably, you're going to have to go back and change it. It may be yourself, six months later or it could be someone else in your team and you can’t understand what the code does – Like if you wrote that code, you know, one line Python list comprehension that does everything. You’re like, “Wait, let me flex here. I got this. I don’t need two lines of code. I don’t need three lines of code. I got it in one.”
[0:05:23.3] MN: You got it at one. Yeah.
[0:05:26.6] DA: Respect.
[0:05:29.1] MN: “I can compact this entire application into one line.” You can do that, as we mentioned before, like the computer may not break, you may not have a compilation error, you may not break any of the rules of the programming language.
But the second story is the story you tell other programmers or your future self about how these whole thing looks. So, the idea is that you are writing a story that other people are going to read. Before, it was the story about how the machine is going to read it, but now it’s how other people, and you yourself, future Bobby out there who needs to extend this particular piece of code may need to understand how the story works. It has to be written well.
[0:06:10.9] DA: Right. I mean, we’ve talked about it a bunch on the show like we’ve talked to the Pragmatic Guys and friend of the show Jacob O’Donnell about clean code. So, if you're like following those kind of ideals of having short methods and good naming and good structure to your code then it can make it more intuitive for people to come back to it in the future.
[0:06:42.2] MN: Examples where this like – when good story telling is told here is when you need to extend this particular feature that you're able to by refactoring and extending unit test and not breaking the software or the feature that has been requested in the first place.
[0:06:59.6] DA: Right, yeah. A good example of like code that reads like a story and might be like, if you have a shopping cart and you're like adding an item to the cart and you have to like the total out, you could do everything in line or you could have – Use other kinds of patterns to structure the code in a way where you have a cart that has items and the cart can tell you what its is. And to get the total, the cart asks its items, you know, what all their prices are and maybe there’s like different tax rolls for the location and that’s super complicated like that’s so complicated, you don’t want that in line in your method there in one line, in your list comprehension. You know, you got to get those tax rolls out of there into their own thing.
[0:07:54.4] MN: Yeah. Then like being able to extend to make it easier. People can understand, other people can extend it without having asking any questions. Like those patterns are important. All of these stories as we’re going through them are important in their own right and now, even looking at the past, thinking about the stories that I’ve written about. Like the way that other people are going to look at the code, it’s very interesting way to look at code, I think.
[0:08:28.7] DA: Yeah, totally. If you're not doing this correctly then you basically got like death by a thousand if’s right there, you know? Classic Jacob O’Donnell quote. Episode number 58 from the tats.
[0:08:45.8] MN: Yeah.
[0:08:48.8] DA: You know, people keep on eyeing one more if statement and one more and then that’s it. You’re done.
[0:08:53.4] MN: Before you know it, you’ve got nested if’s everywhere. You yourself may not even understand the code, eventually someone’s going to have the idea that we need to rewrite the whole thing because it’s a legacy.
[0:09:06.8] DA: It’s all coming back. There’s so many episodes tied in.
[0:09:10.5] MN: Yeah. I mean this middle – the second story is really important and it is really cool to see it as story writing rather than just like programming on a day to day basis.
[0:09:18.9] DA: Yeah that’s true. Programming is a team sport. It’s not just for you. I guess even the team is your future self too because your past self is some other stranger. He’s a jerk.
[0:09:30.2] MN: Yeah, just think about future you, just think about future you while you are writing down these stories.
[0:09:36.6] DA: Yeah. And the last story that you might tell with your application is like the story that users tell about the future. Like the user value that view their story. So, they are going to get something out of it and they’re going to be like, “Wow, that’s really cool.”
[0:09:54.3] MN: Right, so it is like the developer who has figured out how to deliver the user story by talking to the computer and also by talking to other programmers and making it clear so that other programmers understand who makes this new feature much more useful. And when you do that correctly you get clear user value and you can get clear feedback on how people are using this new feature that you implemented.
This was done on the pillar of the first two stories that we spoke about. Because the stakeholders will talk about the future but it was the programmers who ultimately built this thing to work as intended.
[0:10:40.3] DA: Yeah, totally. If it’s going right then people are going to use the software and love it, it will make their lives easier and you’ll get a good fuzzy feeling inside, you know?
[0:10:53.1] MN: Yeah, you know it is great when you get that like people are using your product and everyone does positive reviews about it. It’s great. It’s a great feeling. It is great to get that part as well. An example when this story isn’t told well when it goes wrong is it’s not clear to the users how to use this feature.
And then unfortunately, no one uses the product or it is not useful, which is really lame. So, it is like another thing to think about when you’re telling this story of the feature as a user. You need to ensure that it resonates with the user so that they also use it as well.
[0:11:30.7] DA: Right, yeah. I mean this is like one of the most unfortunate and way too common situations where you think you know what you need to build and you build it but then people don’t come. It’s like, “Oh well, really I just needed this one thing. This one thing that would really make it work like this is just a shadow of I actually need,” or it doesn’t load fast enough or it does have all the capabilities.
[0:12:05.7] MN: Yeah, it is very unfortunate. But when the story isn’t told to all of that it is ultimately what ends up happening, which is really, really lame. So, if you do get the chance to participate in the creation of what this user feature is, ensure that you are targeting the user the way that they would like to and ensure that this is something that they are asking for.
Because when you do tell that story and this clear user value, it’s great. So, make sure you get that. You don’t want to work hard on the first two story writing that you mentioned to then not have a product that’s not being used as much. As you mentioned, Dave, it’s all too common and we can avoid that if we just think about ways to make the story writing for our users better.
When we were thinking about this particular topic, I was wondering if there is a way that I could use past experience to talk about the three stories and what that looked like. So, I am going to try my best right now. I was at a client and the client was getting a lot of users, so much so that they couldn’t keep all the records of identification in one database. They had to use it into two – split into two databases.
[0:13:20.7] DA: So, it’s like sharding?
[0:13:23.3] MN: Yeah, essentially. So, the idea was like for the user, the user should not expect time to increase in terms of identification. They should be able to identify in less than three seconds when they use the application. So that is the user story. Like A, things should be business as usual. If we can make it faster let’s just do so. But right now, it takes about two to three seconds to identify someone. We need to keep that same story intact and the users will definitely be very happy about that.
Because if they get slower then – People want things fast. This is America, right? We want things to be done now, fast food, we got fast food.
[0:14:01.6] DA: French fries.
[0:14:03.5] MN: Yeah what’s going on, I want food in here. I want to be identified and I want French fries. Like that is just what we want.
[0:14:09.5] DA: Yeah, of course, you want fries with that.
[0:14:11.2] MN: Yeah so that was like the user part. So, I am going to skip the second story you mentioned and go straight to the machine. So, the idea was that considering we have to split off the databases from one to two, we needed to come up with an algorithm that would be able to identify, make a request to both databases to find the identification of a user given that if the user existed in one of the two databases, we get the correct one and then we continue on with the identification.
If we check both databases and in the two seconds they weren’t identified, it means that they weren’t in the database and then we let the user know, “Hey, you are not in the application, would you like to register?” Kind of thing. So that you know, the user doesn’t know this concept of like sharding or splitting databases and stuff like that. But like to the computer, we need to say, “Hey, this is a requirement that we need. We need to read it from these two machines. You let me know which one is successful and I’ll take care of it.”
So then this leads to the second story, which is like the story we are telling other programmers and this was done with a class that pretty much made it parallelization call to these two databases. And then made the decision as to which one was successful and what to do with that. And then when we get a successful response, we need to track it and log it and stuff like that and all of this information had to be done in a way that, especially me as a consultant, and once I leave the place people are going to have to extend that beyond me.
So, everyone needed to know and make sure they understood the application so that they can do that. So, it is really weird. Like the user doesn’t know that their identification could be in a database. Or in two or in five or in ten. But it is how you talk to the machine and how do you talk to other programmers about how to extend this application that makes this feature real and possible.
[0:16:04.1] DA: Yeah, totally. And I guess you could imagine the user just wants it to work. That is the third story that as long as it keeps working and it worked quickly, then they’re happy. And there’s no bugs and it is also like convoluted like the way that you do. It sounds like a very technical thing that you have to implement in order to that kind of like sharding of the records and split the work across multiple machines. So, it could pretty easily get complicated or surprising or challenging for other people to pick up. So definitely have to think about the other programmers and your future self as well.
[0:16:43.8] MN: Yeah, if you are listening to this, I would be curious to know if you yourself can think back of times of how your work was broken down into these three specific stories. It would be really interesting. So, now I am definitely going to start thinking in this way of ensuring that I am a story writer. I just happen to use a lot of semicolons.
[0:17:05.9] DA: You’re right. I feel like you know Strunk & White or not as into that or whatever it is thought the standard English style guide. But yeah, I am curious about that too. Like what went, how your stories go well and I am especially curious how do they go horribly wrong? That is always a more interesting thing sometimes.
[0:17:32.5] MN: Oh yeah. And people are going to look back and think of their work as such and I am sure you’ll find a lot of things of how what you may have been successful one and not as successful in the other and think about ways to be more successful in all three. But definitely share the article in the shownotes because I think it is a pretty good dope read all together.
[END OF INTERVIEW]
[0:17:54.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
The Rabbit Hole Episode 58 with Jacob O’Donnell
