Hear about converting Clojure to Morse code, pair programming with non-developers, and other times folks have had the most fun while coding!
In this episode, we talk about the the most fun we’ve had coding with Paula Gearon, semantic web architect at Intelligent Medical Objects, and Lucia Cerchie, software developer at StepZen.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Jeremy Friesen is an open source software developer focused on mentoring, process improvement, and crafting analogies.
Paula Gearon has over 25 years of experience in data management, knowledge engineering, semantic systems, designing large, complex systems, in power supply and distribution, billing and asset management, and traffic and rail control. Paula has expertise in many layers of software systems, from programming operating systems and embedded systems to administration of corporate servers and terabyte databases.
Lucia Cerchie is a software engineer at StepZen.
[00:00:00] PG: Anyway, it’s horrific to look at and it works just fine. I put that back out there and people thought it was absolutely hilarious. I had a lot of fun writing it.
[00:00:20] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem.
[00:00:28] JF: And I’m Jeremy Friesen, Lead Software Engineer at Forem. And today, we’re talking about the most fun we’ve had coding with Paula Gearon, Semantic Web Architect at Intelligent Medical Objects. And Lucia Cerchie, Software Developer at StepZen. Thank you so much for being here.
[00:00:43] LC: Thanks for inviting us.
[00:00:44] PG: Thank you very much.
[00:00:45] BH: So we recently put out a post on DEV asking folks what the most fun they’ve ever had coding was, and we really liked both of your responses. But before we dig into those, can you tell us a bit about your developer backgrounds? Paula, can we start with you?
[00:01:01] PG: Sure. My background is somewhat long. I’ve been doing this for nearly 30 years. I’m Australian. I started my career in Australia and worked in a number of different industries, civil engineering, power systems, and eventually ended up in semantic web, which moved me to the United States in the mid-2000s. And I’ve been working mostly in semantic web. The last six years were at Cisco security, but I’m back in semantic web again now.
[00:01:31] LC: I’m Lucia Cerchie. I am a software engineer from the Southwestern US. I’ve been in tech technically for a couple of years now. I got my start as an elementary school teacher in the professional world and transitioned into tech. I work at StepZen right now. Our old tagline is that we’re a GraphQL API for all of your backends. And one of the most fun coding projects I’ve done there was a recent one called StepZen Import Curl where you can transform any REST endpoint into a deployable GraphQL schema with one command.
[00:02:04] BH: Paula, in our posts, you brought up a neat project that you had a lot of fun coding in Clojure. Can you tell us about that whole story? What exactly was the situation and what made it so fun?
[00:02:19] PG: A friend of mine, Michiel Borkent, over in the Netherlands, who’s writing a system called Babashka, it’s an interpreter for Clojure, and he’s having to reimplement a lot of the Clojure system, which is typically compiled, and discovered that it’s possible to use dots and dashes and keywords and made a facetious comment about how most code could be encoded into keywords in the language. And some people went back and forth on Slack, joking about what you could do with this. And I thought I can do that. So I wrote a little library. I went and found a dictionary of most code online because I don’t remember most code and wrote a function which converted strings in the Morse and Morse back into strings and then strip functions, which did the same with keywords. And I put it out there and people thought it was funny. And someone else made a comment that symbols in the language could also go that way. And I thought about it, and yeah, I could do that as well. Trying to do it, I discovered more ins and outs with the language, can’t use dots in a symbol. I ended up using an ASCII character, the middle dot character, which is still in the extended ASCII set. And then when I had symbols, I thought, “Wait, I could use this to actually encode the project itself in Morse. And so I did. And so now almost all of the source files for this project are Morse code. And there’s like a couple of ASCII words at the beginning, the English, Roman characters, and the rest of it is dots and dashes, the whole project. Everything exported are all in English labels. They don’t appear anywhere in the source code, but it decodes itself. So when you try to import it, it’ll decode itself internally and import the appropriate export, the appropriate symbols for you. Anyway, it’s horrific to look at and it works just fine. I put that back out there and people thought it was absolutely hilarious. I had a lot of fun writing it and I just love the responses I was getting for. People then started saying, “I would use this for useful things,” which makes no sense to me at all, but it makes me happy.
[00:04:35] BH: I feel like different times I’ve had fun coding. A lot of the time it has been some discovery or realization about just how something can be encoded or how some string can be interpreted in a way that when you’re thinking about it, maybe it’s part of what you realize is surprising, but part of it is just you never really put your head in that space. And then once you do it, it’s just a lot of fun. And I don’t know. I feel like certain things that come to mind for me are about how to shove characters in a way that kind of just like messes with your sense of how you’d normally program.
[00:05:10] PG: What you’re saying reminds me of some things that I’ve had in my professional life where I’ve had a conversation, trying to explain to somebody why something was a really bad idea and how it wouldn’t work very well. And in trying to explain this, discovering an entirely new concept, which has led to the next couple of years’ worth of work.
[00:05:30] LC: Can you say more about that? I’m super curious. Is it that the bad idea could be applied somewhere else? Is it that you discovered a principle in explaining the bad idea?
[00:05:40] PG: I discovered a principle in explaining a bad idea. So, I mean, one case I was having a discussion about how all data can be represented in description logics using binary predicates. And I was having a discussion with someone about that as far down as you can go. And we realize that now you can do it with unary predicates, if your predicates can be of various types, but this ends up being a really bad idea and has all sorts of poor issues with it. And I was explaining this to somebody else and they said, “Well, what exactly is wrong about it?” And so trying to explain it ended up going to a whiteboard and pointing out where the issues were. By writing it out, I said, “Well, wait, this is redundant information and this isn’t needed here.” And in the end, ended up with a new indexing system, which I built a database around and it turned out a similar database was created, a triplestore graph database was built around similar principles. That one’s called Parliament. But just in trying to prove why something was wrong, I discovered that actually had characteristics to it that were really useful.
[00:06:52] LC: To me, as a junior developer as well, that’s interesting to hear because the course of my work and coding life, I'm often explaining like, “Well, you can’t do it that way because…” and it’s encouraging to hear that that’s a very helpful thing that I asked the question in many cases.
[00:07:08] JF: I would say yes. Junior developers asking questions, please, it’s a superpower that you have. It’s amazing. I’m really curious about Lucia. You mentioned pair programming in your response. Can you expand on that and the kinds of things you were pairing on?
[00:08:35] LC: Yeah.
[00:08:35] JF: Non-coders?
[00:08:36] LC: Sometimes. It helps to describe what you’re doing to some else. And whether it’s someone who’s more experienced or less experienced with you, there’s never been a time, no matter whether the person is more or less experienced than I am, that I pair programming that I haven’t learned something about what I’m coding.
[00:08:53] JF: That’s really fascinating. I wouldn’t know how to really explain some of this, but it sounds like it’s a very useful tool kind of building on like the Feynman principle of like if you want to learn it, explain it.
[00:09:06] LC: So a lot of it is giving context, right? So in the case with my family members, they had the context because there was a code challenge that Cassidy Williams sent out in her newsletter that I was attempting to solve, but it was to wrap a present in code. So you’d have the length and the width, and then you return the area of the wrapping paper. And I thought, “Well, how could I make this more challenging or fun? Should I wrap like a Klein bottle?” And then I thought, “Well, actually it’s hard in real life to wrap a present because you don’t know the width of the extra paper that you need.” You can’t just transfer the volume or not the volume, the area of the wrapping paper directly onto the present. There’s overlap. So I went to my husband who has a degree in mechanical engineering. And I said, “How would you do that?” So he came up with an equation that would adjust the amount of overlap depending on the ratio between the length and the width and then I transferred that into code. So he was in a way more familiar with the context than I was, but then there’s another way in which you can, it’s almost like treating the person like a rubber duck where as you explain it to them, it makes them more clear in your own mind. But I do think you need to go further and make sure that they understand it as well. And if they understand it as well, they’re often going to see something that you’re not seeing because I believe the power of knowledge increases as it’s shared, because if you’re talking about our understanding of reality, then everybody has a different standpoint on it. And so if you can understand the different standpoints together, then you’ll have a more clear picture and that’s what pair programming brings.
[00:10:36] BH: Does anybody here ever get nervous that they’re going to be exposed for how inefficient their keystrokes are if they find themselves pair programming?
[00:10:47] PG: Well, that happens. And constantly, why are you using this editor? You could be using EMACS. And if you just pressed control, alt key in meta-cokebottle-tea, then it’ll do all of that in a single key press. And like, “I don’t want to learn all of that. I liked my editor.”
[00:11:07] LC: But presented in a kind way, it can help you become so much more efficient too. Like I had a coworker tell me how to use the GitHub extension and check out PR so I can immediately view them in development and I’ve been using that command ever since.
[00:11:23] BH: Oh, yeah, absolutely. I mean, whether explicitly pair programming or not, one thing I miss from working in an office is like learning from what people are doing by happenstance. I find I’m much more likely to come across some opportunity to learn about some small debugging process that may or may not matter in the end, but it’s just something someone’s using that I wouldn’t know to ask about if everybody’s in their silo and I think pair programming is the most fun way to discover some of these things. And I bring up the aspect of terror just in case somebody in the audience is feeling like sweaty palms thinking about it. That’s pretty normal. I think it can be so much fun to them, right?
[00:12:07] PG: I do get anxious even with junior people. So that being shown to be inefficient or just not doing the thing that everyone else does, why don’t you Paula? And I know that it’s going to happen if I’m pairing with people, but I guess I enjoy the process of working with others because it’s the only social contact I get these days.
[00:12:29] LC: I have seen that reluctance in other developers too. Yeah, I would hope that it doesn’t prevent people from getting the experience of pair programming because it can be really enjoyable, but I also get it. I’m pretty sure I have something called proprioceptive disorder and I have a really hard time with my left and my right. So when people are saying the simplest thing, like, “Oh, the button in the left corner,” it’ll take me like 30 seconds because I’m looking at the right corner really, really hard. So I definitely get that.
[00:12:59] PG: I was lucky earlier on in my career. I had this mentor who was someone who just loved teaching things. And then a few years in, I joined this other company who were looking for people and my old mentor I happened to know was looking for work. And so he came back to work with me a second time. And this was the first time I was involved in agile development. And we did a lot of pair programming and I got to work with this original mentor of mine. And through pairing with him, I learned an awful lot more than I had from him previously. I learned a lot about data structures and algorithms that I’ve never encountered before, because I’m an electrical engineer. He was a computer scientist and he was teaching me all of the CS basics that I’ve since encountered in textbooks. But at that point in my career, I hadn’t. And he really lifted my ability to code my understanding of the systems around me to a much higher level. And the process, I guess, also taught me to go out and learn more stuff for myself, but just working with him, he was very encouraging to let me do the driving or he would take over and let me direct how things were, and I’ve seen a lot of people who pair where that doesn’t work very effectively. So I think I was lucky on those occasions when I got to pair up with him, but it was an incredibly educational experience for me. I’ve enjoyed pairing with a lot of people through my career, but certainly early on for me, that was just such an important part of my learning experience.
[00:14:36] LC: Yeah. I think I’ve been lucky as well to have some great partners. Not all pairing sessions are like that, like you said. Sometimes you get a session where someone’s like, “Move up four lines and erase the semicolon,” versus assessing where someone says, “What happens when you run that test?” And that's a totally different experience.
[00:15:14] BH: Jeremy, what’s the most fun you’ve ever had coding?
[00:15:18] JF: This is perhaps not the most fun, but it might’ve been. So I had to migrate a site from an in-house CMS backed by an Oracle database to a CMS in homegrown Rails ecosystem. And I tried to get a data dump from the Oracle DBAs and they couldn’t help me. So I ended up having to scrape the whole site. I then used a precursor to the Ruby Gem, Nokogiri, it’s called Hpricot, to parse the HTML and grab the inner nodes that were relevant for the new site. And we knew the client was exacting. They were very deep into rigorous philosophical theories and proofs. So I built out the outer elements exactly like the old site and then I wired up our CMS to render the inner nodes exactly like the previous one. Well, they said no, it’s broken. And I was like, “I don’t think so.” So I ran a character by character diff to say, “No, these are exactly the same.” And the client was like, “No, it’s broke.” I said, “But they’re the same.” So we went back and looked at some of their very old posts and they were broken in exactly the same way. So they weren’t happy with it, but we could explain like you needed high fidelity because your site has precise, philosophical LaTex renderings and stuff like that. So we were able to say, “Hey, now you can go back and edit it and you’re good to go.” Around the same time, I had another client who told us, “Hey, this has been broken for months or some such thing.” And my supervisor came to me was like, “Has this been broken that long? Because that’s a problem.” And I said, “Well, let me go find out.” So I use Git Bisect. And if you haven’t used that before, it is a wonderful tool where you say this commit is good and this commit is bad and then you have a function that you run, and if it exits with status zero, it’s good, and if it exits with status one, it’s broken. So you run Bisect and it just finds the commit that introduces the break. I did that and it had broken a day and a half before. And what we’re able to do is go back to the client and say, “Hey, I think this was not as long as you said. What’s really going on here?” So we opened this conversation from statistics and we went from this very transactional relationship into a much more rigorous partnership, which was very useful.
[00:17:57] LC: It sounds like code archeology.
[00:17:59] JF: Absolutely. Absolutely.
[00:18:03] PG: So I have a pair of questions.
[00:18:05] JF: Go for it.
[00:18:06] PG: Ben, it was your account that posted the question about the most fun you’ve ever had coding. So I’m wondering what your answer for that is and also what prompted asking the question?
[00:18:19] BH: Lately, and this goes into kind of what we’re doing with DEV in general. If people have been hanging around, they probably seen more of this, but we’re really trying to as much as we possibly can use the format of the site to gather people together to sort of have fun on the edges, learn something about something they didn’t already know and emphasize the stuff that isn’t just, “I’ve got a blog post, I’m putting it out there,” but the sort of thing where my contribution to the community is getting people talking. So I’ve been doing a lot of that and we’re trying to introduce more encouragement for more folks to do that. As you can imagine, this is a tangential answer, but it’s part of what I have fun with what we do. DEV and all the technology we build with Forem is a multi-sided marketplace of ideas and friendship and conversation and the balance of the right types of conversation starters versus interactions. It’s a delicate ecosystem. It’s a balance. So at the end of the day, the motivation for us in this question is, one, to read the answers. I have a lot of fun just seeing who’s out there, especially folks who engage pretty consistently, daily in some of these things. But all that is to say the motivation for asking this is all about getting people to kind of chitchat about stuff that they wouldn’t independently come to read a blog post about if they hadn’t thought about it. It also gives folks the opportunity to not just be a part of something I think when people take part in these threads. They tend to have a lot of fun reminiscing and sharing and you never know when one person kind of finds out about something that used to be personal to you. And it’s like, “Wow! It’s not just one person. Let me see.” Several thousand people read the posts, just like perused it, people love just seeing about people’s experience and stuff like that. Anyway, my answer, which I did put in a thread, was a lot about the early days of DEV and what became our Forem technology and all of that stuff. This also started as a side project, which is a great opportunity to have fun, but it was also a project motivated insignificant part by wanting to really use technology I was actually pretty familiar with, and it was not an effort in deciding as a company what’s the appropriate technology for the right thing. So one of the more fun things about the early days of DEV is that I did it in Ruby on Rails, which I wasn’t using professionally at the time. And the answer I put was think about a time I was procrastinating on something I really needed to do. And I wound up in like one day or two days writing all the comment functionality and the reaction functionality. Logically, most of which is still embedded in the system. I don’t think it’s the cleanest part of the system because it was written in two days when I was procrastinating. It was a lot of fun to make that exist from nothing to something. But as we were talking about some of this stuff, one other thing came to mind. I actually wrote a post about this. One rabbit hole I went down early on in this project. The first design of DEV had a centered title as opposed to left adjusted, which doesn’t take a whole lot of CSS mastery to center something. But one thing I had a lot of fun, I don’t know, problem solving for was how a centered piece of text really looks bad if only like one part of it is on the next line. Optically, it’s kind of challenging to make it look right based on the width of the string, the size of the text, whatever, but the length of a string, like the size, the count of characters does not give you the width, that gives you a number that is not the width, because an I is much slimmer than a W. I went through this whole little project to create a dictionary based on the fonts, which gave me the actual width of the string and pixels relative to the fonts and then monkey patch that onto the string class in the program, which was another bit of just like, “Ah, why not?” Every string can now determine a width. I don’t know. It was so pointless I wound up changing things to less justified and taking this out. And it was stuff that could have been done on the client, but so much of this project was about server-side rendering as a practice or as an exploration. Yeah, so totally pointless, really a waste of time. I am certain no part of this project's success ever had anything to do with whether this like a centered string occasionally looked kind of funny when it was over the wrong number, words were on the wrong lines, but I loved doing it. I learned a lot about how to open up the right file on the backend to create the dictionary and that sort of thing. Yeah. So I don’t know. I feel like I have a handful of other sorts of stories, but those sort of all are kind of interconnected and come to mind. I also feel like the most I anticipate the next most fun I’ll have coding, lately I haven’t been doing much software development on our code base at all, which is sort of like a new thing for me, but has given me the chance to do highly, unimportant, random coding on the side, which has meant that I’ve had a lot of fun coding lately on just random things.
[00:24:05] PG: I really do appreciate you commenting on how you were writing that code as a means of procrastination from other work you had to do.
[00:24:14] BH: Absolutely.
[00:24:16] LC: I feel like low pressure coding is important for staying away from burnout almost, because, I mean, when I procrastinate, it’s usually I have to stop and say, “Why am I procrastinating?” It’s usually I'm tired. But yeah, I’m noticing kind of a common theme in what you all are saying about the most fun you had coding. And it seems like it’s almost a kind of translation each case, like with Jeremy’s mirrored nodes and then Ben’s translating each character into probably a space number and then Paula has got the most obvious translation on the Morse code, making that available and Clojure. It’s just kind of neat to think about that, the fun of translating.
[00:24:58] JF: I heard a CS professor, “All computer science problems are mapping problems. And if you really start to tease that apart even more, all communication problems are mapping problems.” And those are the fun things to try and give it meaning or translation.
[00:25:16] PG: Most problems I have at work are due to people who are miscommunicating. One person thinks, another person thinks something different to what they really said. And being that person in the middle who can translate between them can solve a lot of problems.
[00:25:32] LC: Yeah. I’m still being the person to jump in at a pause and say, “Could it be possible that what we both mean is this?” And I know sometimes they’ll continue to disagree, but occasionally that solves the problem.
[00:27:58] JF: Do you have any examples, Lucia, of procrastinating?
[00:28:02] LC: Sometimes I remember doing this in bootcamp too, which ended up very helpful to me later. I’m procrastinating and sometimes it’s when I’m fatigued by coding, I’ll end up blogging to, I guess, to DEV’s benefit because that’s usually the first place I go. But yeah, I really enjoy doing that, but it also helps me synthesize kind of what’s been making the tide recently. Or it provides less of it because I find that writing is very different from coding and maybe it’s that just because where I’m at and a year into being a professional coder. So I’m still at the sponge stage where I’m absorbing a lot of information. So to write usually is to hand it over to someone else. So I’m changing my perspective for a little bit, and I really, really do enjoy that.
[00:28:56] PG: I found that writing blog posts for DEV have been really useful exercises in procrastination because that act of converting your thoughts into pros can really help you clarify what you’re driving at. I had a library that I was wanting to write and thinking, “This is complex and I’d like other people to be able to contribute maybe and if I can document the whole process of getting there.” And so I started writing a blog series and I didn’t actually finish it, but I did make quite a lot of headway there, but it got me to the point where I thought, “Now I can sit down and actually write this stuff.” And I wrote something entirely new. It was in my own time, but when work found out about it, they said, “Well, can you bring this into our open source projects at work?” And so it started becoming my job. That blog writing on DEV was really an important part of that process.
[00:30:37] PG: But of course, there are languages like Pascal and Delphi, which do start at one.
[00:30:43] LC: Yeah.
[00:31:01] BH: A theme I’ve seen come up a few times in sort of like different language to describe this, I think Lucia, you mentioned that blogging can help you when you’re tired. And I think I was mentioned that refactoring and some of this stuff can occasionally take one out of a bit of burnout and I kind of want to pull the thread of these proactive fun opportunities that sometimes present themselves that are actually the thing that take us out of being tired when I think a lot of the conventional wisdom is that if you're tired from coding, step away from your computer. Both blogging and what amounts to a fun coding activity have a different type of effect, but a positive one. What if folks think about that as far as the antidote for problems when it’s going through it and actually sometimes just be solved from an opportunity to do something that’s a little bit more enjoyable and that’s the catalyst for taking oneself out of being burnt out or, yeah, just exhausted in some way?
[00:32:12] LC: For me, right off the bat, I’ve been thinking about the different side, I'm 100% front-end walking away from the computer, but I think it’s the difference between physical tiredness and then maybe mental tiredness, which can arise from boredom if you’re doing the same thing over and over again, or from overwhelm, if you’re not understanding the same thing over and over again. So if you’re physically tired several times a day, I think we should all get up and walk away from the computers and do something that involves our bodies for a little bit. That will help us physically to code more. But then if you’ve been maybe working on the same problem all week or if you’ve been doing something that’s a little too much in your comfort zone, then I think either a little bit of fatigue or boredom can happen and then taking a little bit of a mental break from what you’ve been on all week and all month and trying something a little bit fun, or even taking away the mental pressure of this is for work or this is for a really important volunteer project or something like that. And just having a little bit of low pressure fun, that’s a little bit different from what you’ve been doing can be a real refresher for your minds. But that’s my take on it.
[00:33:22] PG: I absolutely agree. I mean, some of these things like the working on that talk for the conference where I procrastinated into a math library, at that point, I was really feeling burnt out at work. I had an open source project that I’m running, that I knew I needed to get some things done for, and just the pressure of that I didn’t have any desire to do it. Work was not going well. That’s one of the reasons I’m now in a new job, but the opportunity to just leave it and focus on something that I was finding fun and enjoyable and there were no external expectations of me doing it at all, that fun really revitalized me and it helped me focus on what I needed to do in my personal life and at work and reminded me that I actually enjoy working with computers. I know that we’re told that you’ve got to take a break. If you’re getting burned out, you want at least a vacation, if not a longer sabbatical, but that isn’t always possible. And I find that sometimes just going off into something, which I suppose more work from one perspective, but just fun really, just helps reset my mind and allows me to re-engage with the other things in my life.
[00:34:41] LC: Finding a little joy in something every day I think it’s really important for just being happy, both at work, at home, but just having a little something to tinker with that makes you happy is really energizing.
[00:34:55] JF: Paula and Lucia, it’s just been great to have you. And do you have any other thoughts on this about pairing, math libraries, fun times, character encoding?
[00:35:06] PG: Keep coming back to do some of this fun stuff now. My new job is not actually software engineering. It’s architecture. I spend a lot of time in meetings with people, setting direction of where people are supposed to be going, things like that, but I miss the coding. And having these fun projects to come back to, things that I enjoy and want to do are keeping me mentally engaged I think. And I think having this habit of occasionally just dropping all my requirements and just sticking to something that looks like fun for a bit, that’s been really worthwhile for me. And I think it’s helping me stay in touch with the things that brought me into this industry in the first place.
[00:35:53] LC: I’ve enjoyed “meeting” you on this podcast, Paula. It means a lot to me as a woman in STEM to see someone so much further along in their career path than I am, still enjoying it, but also just to hear what you’ve done has been really cool to hear about all those math libraries and things that you’ve worked on. That’s been fun.
[00:36:14] BH: Thank you both for joining us today.
[00:36:17] LC: Yeah.
[00:36:17] PG: Thank you very much.
[00:36:18] LC: Have a good one.
[00:36:28] BH: Thank you for listening to DevDiscuss. This show is produced by Gabe Segura. Our senior producer is Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern Time. Or if you want to start your own discussion, write a post on DEV using the tag “discuss”. Please rate and subscribe to this show on Apple Podcasts.