Many programmers settle into a work-life balance where their day job pays their bills and their side projects fuel their passions. UI programmer Kofi Gumbs sees his side projects as opportunities to grow.

In our latest episode of Collaborative Craft, we talked to Kofi about making design playful. He shared insights on why programmers need to develop the confidence not to reinvent the wheel, the role of ambitious design, and how to approach the process of design in a way that is motivating to you.

“I feel like the whole process has to feel like play as I'm working on it or else I get bored. I have to be learning something new. One of the reasons my solo projects end up being so all over the place is because I want to have a little play and chaos in my growth as a developer and to keep me energized in general.”

— Kofi Gumbs

Listen for Kofi’s ideas in our new episode, and see if you can infuse your work with a sense of curiosity and wonder.

Kofi Gumbs is a UI programmer currently based in Baltimore, MD, where he works remotely for Twitter. Most of his professional work centers on the Web platform, but Kofi's personal projects span a much wider spectrum—from assembly compilers to realtime graphics and audio. You can keep up with his side projects by following him on Twitter.

If you'd like to receive new episodes as they're published, please subscribe to Collaborative Craft in Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts. If you enjoyed this episode, please consider leaving a review in Apple Podcasts. It really helps others find the show.

This podcast was produced by Dante32.

Episode Transcript

Stealing Fire: Ambitious Side Projects with Kofi Gumbs

[00:00:00] Jerome: I can count us in.

[00:00:02] Thomas: Okay.

[00:00:03] Jerome: 4, 3, 2... Welcome to The Collaborative P- [laughter]... Collaborative Podcast?

[00:00:12] Thomas: I'll start. And then you start. And then I'll read Kofi's bio.

[00:00:16] Jerome: Okay. Yeah, that makes sense.

[00:00:17] Thomas: You know what I mean?

[00:00:18] Jerome: Yeah, yeah, yeah, that makes sense.

[00:00:19] Thomas: Kofi, we have done this before. [Laughter].

[00:00:23] Jerome: This is impressive.

[00:00:28] Thomas: Hello everyone. I'm Thomas Countz.

[00:00:31] Jerome: And I'm Jerome Goodrich.

[00:00:32] Thomas: And you're listening to Collaborative Craft. A podcast brought to you by 8th Light.

[00:00:39] Jerome: So, Thomas, who's our guest for today?

[00:00:42] Thomas: I'm so glad you asked, Jerome. Today we're talking with Kofi Gumbs. Kofi is a programmer based in Baltimore, Maryland, where he works as a front-end engineer at Twitter. As well as being a former 8th Light-er and Recurse Center Alum, Kofi is known around the internet for his many personal projects, which include codec-beam, which is an Erlang VM Bytecode Assembler for generating beam instructions from Haskell, which I believe you contributed to Jerome...?

[00:01:12] Jerome: That's right. I did

[00:01:13] Thomas: Multi, one of Kofi's latest experiments with building a low code platform for turning a group of websites into a native macOS experience. And Type Beat, a beautifully designed software sequencer that he's teased on Twitter. As a serial experimenter, Kofi's ability to ship is awesome to follow. And we're eager to learn more about how his approach to side projects might influence our approach to crafting software at work, which are often very different things.

[00:01:44] Jerome: Super different. I am thrilled to talk to Kofi. Kofi was a bit of a mentor to me when I started at 8th Light. And as an aspirational side project, let's say, I'm really eager to kind of hear from the master. Side projects are always something I've wanted to do. Always something I get started on, but never something I get very far with. And like you mentioned in his bio, Kofi did give me a bit of an education in both side projects and Haskell and Open-Source. I believe that was my first Open-Source Contribution. And so, yeah, just really excited to catch up with Kofi and hear more about, you know, how he thinks about side projects and how that can relate to the craft of building software.

[00:02:34] Thomas: I'm in the same boat. I am an aspirational, serial experimenter. I love side projects. I feel like I have a ton of them. But unlike Kofi, I don't ship nearly as often. And my side projects are not nearly as polished as his. He somehow takes all of the energy, creativity, curiosity, and oomph that I feel like I have, and he actually turns it into a final product and I always get stuck somewhere. And I feel like many people do. When I talk to people about this problem, I know I'm not alone. You have all these ideas and then somehow it just like something gets in the way or you lose track of time. Or, you know, it's a million things.

[00:03:21] Jerome: There's a little bit of magic, right? That's missing. Hopefully Kofi can let us in on the secret.

[00:03:29] Thomas: I mean, I feel like if my projects looked as good as his does, I would also be very motivated to get them done.

[00:03:35] Jerome: That's a fair point. I mean, he presents very well.

[00:03:40] Thomas: One thing that I want to say about side projects is there's a lot of baggage about it I think in the industry. Like a lot of people feel like they have to. Or they feel rebellious against it, cause they're like "I code all day at work. I don't want to do side projects at home." And so like, I really like to square the idea of side projects as like, it's your hobby, it's the thing you're doing instead of knitting or fixing a motorcycle or doing, you know, going to, I dunno, conventions. Whatever people do as hobbies. What was I thinking of? Cosplay! Cosplay Conventions.

[00:04:16] Jerome: Oh like, Comic-Con.

[00:04:17] Thomas: Exactly. Like, those things are your hobby and you put a lot of yourself into it and the same with code and just because it's what you do for work, it doesn't mean you have to have that as your hobby. It's just, you know, some people do.

[00:04:27] Jerome: Yeah, yeah. I think that resonates a lot with me as somebody who is maybe in that camp of, "Oh, I code for a living, why...? You know, why should I also code on my off-time? Like, give me a little bit of variety." But then seeing, you know... There's still that allure, there's still like, I want to use my skills to make something that isn't a fulfillment platform or an invoicing web app or something like that. And I'm really excited to just hear how Kofi approaches it, because I think it really is a mindset and a mentality that maybe we can bring into our daily work.

[00:05:08] Thomas: Exactly. Can we approach our day-to-day work for our employers writing code with the same kind of energy and excitement and motivation as Kofi has with his side projects?

[00:05:20] Jerome: Absolutely. Alright, without further ado, let's talk to Kofi.

[00:05:30] Thomas: Thank you so much for being here, Kofi and welcome to Collaborative Craft.

[00:05:34] Jerome: Thank you.

[00:05:36] Kofi: Thank you two.

[00:05:37] Thomas: Cool. So I guess we can just dive in to talk about what gets you excited? What gets you motivated? Like your projects, even just the few that I read off in the intro are so diverse in terms of like, some of them are kind of like building a language and a compiler. Some are very creative and artistic. So they really span the gamut. How do you get started? Where does the inspiration come from? How do you say yes to an idea?

[00:06:08] Jerome: And to piggyback, maybe even more, I'm really curious about like, what makes you think that you can do these things?

[00:06:15] Thomas: [Laughter] Who gave you the right?

[00:06:18] Jerome: Exactly. No, I mean, like, I look at some of your projects and I'm like, I would never have started because I would never think that I could actually do anything, you know?

[00:06:31] Kofi: Codec-beam acts with the Haskell package is basically me copying what exists in the Erlang compiler. And so knowing that it does exist already makes it kind of feel like... you know, this is achievable. It's like someone has done it and they have put it up online for me to look at for free. And so that gives me a huge headstart. And so I know it's doable.

[00:07:03] Thomas: So, sorry, just to- is that your like "Sunday reading" is to go and read...?

[00:07:08] Jerome: I was gonna say like, so instead of reading Game of Thrones or like... Kofi pops open GitHub and starts reading and compiling... [Laughter].

[00:07:16] Thomas: You could do a New York Times Crossword or... [Laughter].

[00:07:19] Kofi: I've skipped some steps, I've skipped some steps. And actually, my brothers at one point would make fun of me because I would read GitHub code on my phone sometimes. They'd just assume I was reading tweets, but it was always, it's always in service of something specific. So I think that, yeah, I guess backing up even further, the core of that codec, what became to be known as codec-beam was originally called elm-beam, kind of. It was just me wanting to write Elm on the back end. And that was literally the extent to which like kind of the initial versions of this whole thing were born. I've tried a few approaches, actually. Jerome was there with me when I was trying some of these, while I worked at 8th Light. I tried like an elm to LLVM and elm to seed compiler.

Those are both doable projects, too. And I think actually people in the community, in Elm community have done them. But this was like a year or two into my career. And I didn't understand those languages well enough to do it. I wanted to do it, but I didn't understand kind of that level of tool. So I looked for something that was a little higher level and easier to understand. And that's how I ended up in the beam internals, because Erlang internally is very similar to Elm. And so like at that point, I'm like, I'm telling you this story, I guess, super quickly. But at that point I'm like six or eight months into this journey. And the project is still all about getting home to the backend.

So, but at this point I'm like working on understanding the Erlang compilers internal, right. So it's like very, I ended up working on something that is very much a bike shed from the original project-stated goals. But it still felt connected enough to me. And as I continued working on it, I realized this is actually probably its own thing. And that's how codec-beam kind of came around. So it was kind of like, I had a very concrete goal at first. And I ended up with a pretty concrete artifact, but it did not actually resemble or meet the goals that I originally outlined. And so I just called it something else. And then used it to build the original thing, is kind of how that project ended up going.

The multi app that you mentioned at the start, Thomas, was actually the exact same story. Now that I'm thinking about it, it actually is the exact same story. But it was a lot more recent, so it took a lot less time. It was only over the course of a few months. But I just called it a chat app. I slipped- because in my mind it was a chat app, at first. I wanted to build an app because I was like, I'm logged into Zulip, which is a chat app. I'm logged into Slack and Discord. And I juggle between them.

[00:10:04] Jerome: Your computer is overheating. [Laughter].

[00:10:06] Kofi: Kind of. It's just more that, like, I don't like the mental space of knowing I have these, like- I start my day- I like to close my apps at the end of the day. And so when I start my day, I have to open the regular ones and I have to do it three times. And then in my tabs- which I always have three entries, when in my mind, it's like one... I go there for one reason, you know? So I started to- I was just going to build a chat app that had- it was just a web view, a series of web views. One web view for Discord, one web view for Slack, one web view for Zulip. And then as I started building it, I was like, you know, actually, there's no reason this is just limited to chat. This is actually, you know, I could put any URL in here and have an app that has tabs. And in fact, I can make the URL dynamically, configurable.

And then when I finished that, I realized that this thing actually doesn't do chat at all.[Laughter]. It's a web browser kind of. It's a very minimal web browser that lets you kind of make it feel a little more native. So I published it as that. And then I used it to make the chat app. So I guess that's the thread so far. The music sequence that you mentioned maybe doesn't fall under that yet, because it's in progress.

[00:11:24] Jerome: Ah, just give it time, right?

[00:11:25] Kofi: Yeah.

[00:11:27] Thomas: It's so pretty to look at and to hear because you recorded some videos of it. But it just looks so inviting, like you want to play. And I mean, I wouldn't call myself a musician. I played instruments at points in my life, but there's something about the way you've designed it that feels like, "oh, I want to interact with this. I want to see what it does. I want to figure it out." So we'll definitely include the link to that.

[00:11:56] Kofi: That's awesome. That was my main goal. So it's really cool to hear. It's also a little funny to hear because I've changed the design, oh, quite a bit. So yeah, hopefully the new version still feels inviting. But yeah, that's the goal to make it kind of like, make it feel hands- it's a computer program, but I want it to feel like you're touching it and that you could touch any part of it to make a different piece of sound come out, and that should feel like a safe and playful experience.

[00:12:37] Jerome: That's so cool.

[00:12:39] Thomas: I love that word "playful" because all of the projects of yours that- well, even the way you're describing the arc of them, it feels so playful. And it reminds me of the stories. You hear- sorry, I'm going to say back in the day, but I'm a relatively young programmer- but like, you know, OG computers nerds that like they got a computer at home and then the first thing you do is you like hack away at it and you customize it and you build the- you just like experiment with it. And there's a lot of play and fun and curiosity. And I mean, just again, the breadth of the projects that you work on to me, just screams being like curious or wanting to figure something out or optimize something or tweak something, make it your own. And there just isn't a lot... Or there isn't as much of that maybe with consumer electronics today, because everything's so like tailored. But it sounds like you, you really carve out like a piece of tech for yourself and it's really cool to see. And yeah, it seems very playful.

[00:13:41] Kofi: It's definitely playful to me. I think... This music app I'm working on, it might be one of the first ones that I intended to be playful for others, but I feel like the whole process has to feel like play to some degree as I'm working on it or else I get bored. So, I have to be learning something it's becoming a little bit rarer that I'm kind of learning fundamentally new things at work. And I think it's fine and part of the job. I just code a lot of react and I learn a little more about react everyday, I guess, but it's not kind of fundamental paradigm shifting kind of stuff. But I feel like some of the reason that my solo projects end up being so all over the place is because I want to have a little play and chaos as part of my, kind of growth as a developer and just kind of keeping me energized in general.

[00:14:49] Jerome: Yeah. I love that. As I was kind of prepping for this episode, I was thinking about that kind of MVPs all the way down. Thinking about that playful, chaotic nature to some of your personal projects. And I realized that there's actually a pretty interesting- to me, at least- thread between that and kind of this new directive we have at 8th Light of like ambitious projects, custom solutions to ambitious projects or problems. And it like occurs to me that pretty much like every single one of your personal projects started with like a pretty ambitious kind of goal and the role of play and the role of chaos and the role of kind of, not really knowing where it's going and iterating and rolling with the punches and coming out with something that is totally different than what you intended, to me speaks a lot about the process of trying to solve ambitious projects. And I'm wondering if you have anything to say about that, if that sparks anything for you?

[00:16:07] Kofi: Yeah. I think that when you have a project or some kind of unit that feels opaque, I guess. And where you're not sure what are the smaller pieces here? Cause I think, iteration as a software developer is almost entirely about working on the smaller pieces, working on classes or modules. And in those classes and modules, working on like structures or functions. And it's hard to see, you know, the classes, if you don't understand the blob yet. Yeah, I think for me, one advantage I have doing... One thing I'm grateful for is that I am living in this era where so much source code is available to me on GitHub. And yeah, I mentioned my brother's poking fun at the fact that I do like have- GitHubs probably one of my top visited sites on my phone. You can answer questions today instantly that you might not have been able to think about how to ask them not too long ago.

And so, yeah, I do a lot of code search on GitHub, just to figure out, like, have people done this project in this language? If they didn't do it in this language, what language did they do it in? Like, what- has anyone done a big project in it? If so, like how did they lay out their- like how did they think about the domain?

You can look at like, just their file structure and see like, "oh, these are the concepts that, you know, five people use, I guess these are probably worth maybe understanding from a, if I want to understand this domain perspective."

[00:18:01] Jerome: That's really interesting because I feel like I do not leverage GitHub as much as like, it would be useful to use it, right? Like, GitHub is where I push my source code. And it's not like a compendium of knowledge that I can draw upon. I know other developers that, like yourself, that use it really effectively. And it makes sense to me, especially if, you know, talking about like ambitious projects to kind of stand on the shoulders of giants, right? Like, look at the work that's come before. Do you have any tips? Any like suggestions or practical ways that me or people like me might be able to leverage GitHub more effectively.

[00:18:59] Thomas: Yeah. GitHub copilot, right?

[00:19:03] Jerome: Boom!

[00:19:05] Kofi: Boom! Yeah. I think a place that I started was just start projects. Like my personal start projects, even before I started actually reading code, I would see a project on Hacker News and say, oh that is an interesting product and I'm going to start it maybe as like a, "I liked the tweet" kind of energy. But a lot of, you know, a lot of like small to medium-sized projects are- have a handful of key insights. Like you can imagine like seeing react for the first time and thinking, oh, this is magic. And then understanding from some of their internal documentation. Okay, one of the key insights here is, you know, how they manage, you know, directional data flow and the virtual DOM.

And now you have kind of two ideas that you can hunt through the repo and find virtual DOM that JS or similar. And that you've like stumbled upon what the developer's name as kind of the crux of the thing. And a lot of times just reading that file could point you to the, the interesting part. Which is kind of one thing, for me, inside projects- like making sure you're doing as much of the interesting part as possible is kind of a constant tension right there are hundreds of files inside of final products a lot of time. But in the same way that like, I spend energy when I'm writing projects and cutting out, what is the non-essential piece of this idea? It's kind of like the inverse process of finding in other people's projects. Like what exactly is going on in this project that kind of looks like magic to me from the outside?

A part of how I got to Multi was doing that for the- there's a library, a C library called webview, which is just a cross-platform kind of wrapper around native platform web views. Pretty much every major desktop platform has one. And so you can kind of ship desktop apps by making a website and shipping the HTML JS and CSS, and then shipping a very small generic C layer around that. That's the actual executable. And so reading the code for that library, you know, the part of it where they create the Mac app is so tiny. And you know, some of it is like, well, if I don't need this feature that they just added cause there's a GitHub issue that asks for it, then it becomes even tinier.

And so like that core idea was the first version of Multi and then kind of adding bells and whistles I felt to be necessary for Multi's success that didn't exist there.

[00:21:58] Thomas: I love that. I don't- it either sounds like really stuck up or like, I don't know, what's the word like degrading to say to someone, but the advice I always give to people is to read source code. I don't do it as much as I, you know, want to, but I do read source code for fun. And especially if you're working on a project, like... People talk about- I work a lot in Rails. And people are always like, well, there you have it right there. You just like open it up and look at it. And really, it really is approachable code and you don't always agree with it, but it's, what's there. And by reading it, you gain a lot of understanding. And I think always going to the source is, like- you explained that it just makes me want to read more code because really, like you said, it, it's not magic. It's people that are just like us who are writing this. So it is possible. There is a way to do it. And like you said, we live in a time where you get access to all of that for free. So yeah. I want like a library, like a bookshelf behind me, but just like source code, like, "oh, I'll read this today."

[00:23:11] Kofi: It was really freeing for me to think about it from the inverse perspective. Not just looking for things I want, but looking for things that are bugging me, like, why does you know, why is this bug here?

And I just remember the first, maybe the second year of my career, my first Open-Source Contribution feeling like, "Oh, wow. Like this thing that I took to be an artifact is inspectable. And I just helped fix it because I took the time to kind of read it. And not that the fix was particularly hard, but it's, you know, it's just, these things are built by people who have fixed hours in their day and priorities in their lives. And it's the coolest part about software to me that it's figure-out-able.

[00:24:04] Thomas: I want to circle back to, or I guess, we haven't really gotten to it yet, but this idea of MVPs all the way down. And to something that, I mean, I think you were still chewing it over, but this idea of like a project only existing in a single file? And why I'm interested in it is because, you know, a lot of what we try to talk about on this podcast is related to the day-to-day work. The work that, you know, we sit down at a desk and do our work for our employers. And in here we're talking about side projects, but there's so much about the way that you approach things and the way that you see things that I think are really inspiring to bring back to work. Like, can we find the play in work when we're approaching problems? And can we feel confident finding solutions rather than like reinventing the wheel? Like just really having our fingers into the industry and what's out there to be able to like pull inspiration from. It doesn't have to be like all in our institutions, or organizations, or all in our head. So I want to dive into your ideas, even though you approach your side projects this way, like, I think we can carry a lot of that curiosity in with work or into work. So yeah, I'd love for you to dive into kind of your theories about your personal projects.

[00:25:23] Kofi: Sure. Yeah. It's yeah, I hinted at it just now with thinking about like, what is the interesting part about this project? And to stay motivated for me, you know, I've gotta be spending most of my time on the interesting part. And so I think one of the reasons I end up with sub projects is because when I find myself spending a lot of time on something that feels uninteresting to the thing that I'm trying to do, I want to kind of do it once and be done with it, you know. Make that the interesting part for a few weeks and then finish it and then go on to the thing that I originally thought was the interesting part. And so the idea with, I mentioned this, like keeping everything in a single file. It's such a, like, it's kind of how I like to speak just in absolutes for no reason, I guess... And as a concrete example, this music sequencer I've been working on, I have like three JavaScript files. There's one called index.JS, which is the thing. And then one called- I don't remember what they're called. It doesn't matter what they're called now, but I just put everything in that index.JS.

And then it feels at a certain point, like, dang there are mixed levels of abstraction here. And, you know, I have, the top half of this file feels different from the bottom half. The bottom half is the app. The top half is plumbing. So, I put one in plumbing.JS or something. And then I have my actual, my app in index .JS.

Now plumbing.JS to me should feel done to some degree or definition of done. Where like, once I take it out of that, of the app context, which is to me the single file, I want it to be finished and just work as a dependency to my main file. And so that is where I started thinking like, "dang, maybe when I pull it out of the file, I should just pull it out of the project" because I don't even want to like- obviously there are circumstances I have to redesign. I refactor and there are practical reasons why it probably doesn't make sense to like actually pull it out of the, Git repo, let's say. But conceptually, it's not a part of the thing I'm trying to build.

It's a layer below. And especially when I'm thinking from the perspective that I want to build something that I will be sharing publicly on GitHub. I don't want anyone who tries to do something very similar to what I'm doing to have to kind of pick apart which pieces apply to them. Like they should be layers that they could feel like, okay, if I copy everything from this directory down, I'll have this little bit, and I can build my own version on top of that or something like that.

[00:28:26] Jerome: It's almost like you're doing a public service. To others that I think the same way as you of like trying to find the interesting in source code and just making it easy for them.

[00:28:37] Kofi: Yeah. I was hesitant when you said public service, but when you say to people who think the same way as me is, yeah. That's probably it. Yeah. I mean coding the way I think, or I'm trying to encode the way I think, in the project structure so that anyone who thinks similarly will have easy time. I guess the jury is still out as to like how many of us there are, but

[00:28:59] Thomas: Alright, everyone go read Kofi's GitHub. [Laughter]. Star it if you think the way he does and just don't do anything if you don't. Wait, Kofi, do you, do you write tests for these things? Nobody clutch their pearls now, I'm just wondering.

[00:29:18] Kofi: Usually not. Codec-beam has very good test coverage actually. And I was very proud of those- I am very proud of those tests. However, I feel like the only reason the test coverage got there is because I started to treat the tests as their own project. Like there's some interesting mechanics going on with, how do you test the code generation language for bytecode? Like without just putting arbitrary blobs of bytecode in your like test stubs files. So, because the tests were interesting, I wrote them. A lot of the times to me, the tests aren't interesting and I skip 'em.

[00:29:55] Thomas: That's okay. I asked because like, yeah, I can imagine if you... I mean, okay. We're not here to debate like the importance of tests and TDD. And I think in our professional lives, definitely if you work at 8th Light, you write tests. But in terms of these projects, like, it sounds like there's a way that these abstractions reveal themselves that allow for you to almost hold it all in your head. Like the mental model of it is so close to what it actually is because you've spent so much time discovering the abstractions. And not saying you don't need tests, but you have a higher degree of confidence than you would if you had like a 15 file JS project.

[00:30:43] Kofi: No, I think you're a hundred percent right. And I'm actually surprised that I didn't use the phrase, hold it in your head so far, because I love that phrase and I use it a lot to talk about design. Because I think that is, to me, that ended up being the main point of tests: to hold context concretely in an artifact.

That's not your head because when you're working on a team in particular, especially, you know, a real world team where people come in and out of, they can't be in any single developer's head. But when I'm working on stuff, that's just, I'm working on it. I feel like that's a totally fine trade-off. And so to me, as I started working more on solo projects, one other aspect I hadn't thought about as far as keeping context in my head is how easy is it for me to reload the context, if I need to come back to the project. And I don't always love coming back to projects, but I do have to sometimes like Multi is a thing that I sell. And so when bugs come up, I try to fix them. But I'm working on it maybe like one weekend a month at this point. And so I actually have a hard time with Multi because it's in a language I don't otherwise use, Swift.

And because of the nature of like how you have to inherit from certain classes and stuff to bank, a Mac app, there are a bunch of like structures and the structures live in different files. And so I have some trouble kind of coming back to it. And so I'm trying to be a little more strict about that in this sequence rap I'm building, because when I put it away for some time and come back to it, I want it to feel like all the stuff I'm looking at is the app. It's, you know, the layers are somewhere else. And when I, you know, look at the directory structure and when I look at the like main functions and code structures, they should remind me of like, the analogies that I used originally to name these sub components.

[00:32:57] Jerome: Yeah. The first thing that pops into my head is like, how does that, that idealized kind of workflow work for you in your day job? Like how do you square that circle? Right? Like, is that a source of frustration?

[00:33:13] Kofi: I'm no longer frustrated. I think there was a time I was. But I think that I am now maybe at a certain stage of grief where I've accepted the fact that it's very different.

It's very different. You know, I have to write a lot of uninteresting code at work and it's not just where I work. I think anywhere, like you can't just pull out a chunk of code and Open-Source it, you know, at-will and a lot of- well, you know, one thing I realized, actually not at, not at my current job, but I worked at a logistics startup before and we did a lot, we did invoice processing and it was rare that we were kind of the source of truth because it was a start up so we had to integrate with like a bunch of older data systems. And then it was like a two-way integration a lot of times, pull data from them and then let people do whatever they wanted with it in our system, and then push it back to their kind of home database.

And there were a few companies doing similar things. And whenever customers would talk about why did they stick with our product? They would say the integrations work and they're consistent. And they were so, from the inside, they just felt so like not- they felt like not the thing. Right. They felt like they're just the pipes that take the data in and out. And then we, and then we have the thing and then the data goes back in or out. Right. But from the customer's perspective, like that was the reason that a lot of people had tried other products and said like your integrations work.

And the integrations always felt to me like, oh, we're just, you know, we're programming reactively. We don't really have, like organization area. Cause we're just like. Like building on, on legacy systems on their end. And, but so much of the value we delivered came from the stuff that to me is uninteresting to work on independently.

So, yeah, right before I started my current job, I worked on my own product for awhile. It was for personal trainers. My wife's a personal trainer. And so she was user number one and still a user. And I think I fell into the same trap and that's kind of what solidified it for me that like, man, to build a business it's you have to be able to treat the stuff that's maybe not interesting from a programming perspective as like, you know, the thing that you do to eat kind of.

So like, I do want to try it again, see if I can, you know, take another shot at making that kind of work interesting to me. But yeah, at the time I tried it, I felt like that was a constant fight of like, man, I want to be programming. What I view as the thing, which is maybe not what a customer might be needing as their thing.

[00:36:11] Jerome: It seems like a yin and yang, right? Like on the one hand, I think it's really great to be programming things that you're excited about and developing your own philosophy of how to deliver interesting, in some ways, content for other Kofi's out

[00:36:34] Kofi: there.

[00:36:36] Jerome: But I really appreciate the acknowledgement that some of the unsexy stuff.

Is also very important, even if it's not particularly interesting to you and both kind of go into creating lasting projects and there's room for both. Right.

[00:36:53] Kofi: If I could take the version of myself that does work and is cool with that. And then have a copy that is the side project who is kind of saying these big, crazy projects and.

Working on the interesting bits and they repair it. I feel like that might be my, my startup team for like- but personally I just, I don't know how to switch, you know, effectively navigate that in one body. But if I had two bodies, that would be great.

[00:37:22] Jerome: Co-pilot. [Laughter].

[00:37:25] Thomas: I have to say like sometimes. And I think it's, it's totally legitimate and healthy and valid to admit that like the work of a programmer, isn't just the sexy things.

And it's why I think when you have like a really good project or product manager where it can be really interesting and fun because they have that kind of touch with the user and the customer, and you really can understand why that unsexy stuff needs to be done. But even with that, I totally pretend sometimes when I'm working that I'm like working at JPL or like NASA or something, and I'm like, I know working on an invoicing system, but I'm going to pretend like these are invoices for NASA, and then it'll be fun and interesting, right?

[00:38:16] Kofi: Look, whatever works for you.

[00:38:19] Thomas: I honestly thought everyone thought that way and then I told my team that, and they were like "What? You're crazy!" And I was like, oh, I guess I am.

[00:38:26] Jerome: I want to use that now. I think that's- it reminds me of the- Neil Gaiman has like a commencement speech that people love, but just like make good art. And one of the things that he says in there is like, if you don't know how to do something, like pretend that you are somebody that enjoys doing it, and do what that person would do.

I think unless Thomas, you have any questions, maybe we can wrap it up.

[00:38:53] Thomas: Yeah. I think we're we're about at time. Kofi, thank you so much. So much. This has been a really awesome conversation. We've had a few- I think you- I don't know if you called them "drive by's" on Twitter. We passed by, on Twitter a few times and like I said, I've been following your side projects and as a serial side project-er, even though mine are never complete, I was always inspired by your work. So I was really excited to have this conversation.

[00:39:24] Kofi: Thank you. This was, yeah, this was a lot of fun. I am glad that we got to it. I'm glad that it could, you know, help however you're thinking about your work.

[00:39:34] Jerome: Yeah. How can the people on the interwebs find out about you and kind of keep abreast of the stuff that you're working on?

[00:39:42] Kofi: I'm @KofiGumbs on Twitter. I'm also KofiGumbs on GitHub. If via this conversation, you're like, "I like the way that, you know, this guy might think, might organize his code," then, you know, we can talk on either of those.

[00:39:57] Jerome: Collaborate maybe?

[00:39:58] Kofi: Yeah.

[00:39:59] Thomas: I'm definitely going to go read your source code. Hey listeners, maybe we can, we can hang out in the issues and open a bunch of... [Laughter].

[00:40:07] Jerome: I can vouch for being a collaborative with Kofi. He's great. He's great to work with. Yeah.

[00:40:12] Thomas: Well, yeah, thanks again so much. And yeah, we'll be sure to include all of that information in the show notes.

[00:40:20] Jerome: Yeah, this is awesome. Thanks Kofi.

[00:40:23] Kofi: Thank you.

[00:40:29] Thomas: Oh, another fantastic conversation.

[00:40:32] Jerome: Absolutely.

[00:40:33] Thomas: I feel like I always walk away with these and I'm like super excited to do something. I'm like, what do I do with this energy? I know what I maybe want to do with all this energy, but I'm curious for you, Jerome, how did that hit for you? What resonated? What are you sparked with?

[00:40:49] Jerome: Yeah. See, I'm interrupting you because I'm so excited to talk about it. I mean, my biggest takeaway is that I'm clearly using GitHub incorrectly, or at least not to its full potential. You know, I'm saying that a little tongue in cheek, but I think Kofi made a really compelling case for a really interesting way to make something from nothing.

You don't start with nothing. Like, it's so obvious. But like, you know, most powerful things are. If I'm going to write a blog post, I'm going to do some initial research or I'm going to have some notes I can draw on or at the very least, you know, read something that sparks something for me. And I've just never really thought about code in the same way.

I mean, you know, there's a little bit of the CopyPasta approach and taking from like tutorials and understanding how to do a particular thing, stack overflow, that kind of stuff. But I've never really thought about looking at a code base at somebody else's code and trying to find the kernel of what makes that code really interesting.

And so that, for me, is super exciting and I'm tempted to start, you know, a side project now. We'll see how far I get, but I think just having that guidepost of like, "Oh yeah, what is the interesting thing here? Where can I really pull out something that gets my mind going? That gets me thinking, 'what can I do with this?'" I think hopefully that'll be motivating enough for me to at least complete something and ship it like Kofi does.

[00:42:24] Thomas: Yeah. A hundred percent. And I don't think I've ever used GitHub to its full extent like that either..? I think I've approached it, but it seems so, like obvious. Yeah. When Kofi says it you're like, oh yeah, definitely you should be inspired by other people's work. What really hit for me, like I talked about in the beginning, I am always experimenting and always trying new things. And the one thing that Kofi was talking about that I think would help inspire me is specifically like how to load and unload it from your head. And the way that he approaches it is like, really scope things down. Work on the thing that's the most interesting and make it small enough that you can fit it in your head. And when there's something that needs to like support it, make that its own thing. Get that out of the way, knock it out, call it done and get back to the thing that you think is interesting.

I think a lot of my... I would say a lot of my personal projects are very ambitious. At least ambitious to me. They're usually in a domain I don't really know a lot about. Or they're using some sort of, or several pieces of technology or languages or frameworks that I haven't worked in before. So there's a lot to do and it can get very overwhelming.

So I'm like, "ah, I wanna like go back to one of my projects" and I'm like clear all of that out, focus on like the really small kind of thing. Call it done. Get other pieces out of the way. And it's also like a really cool way to manage those dependencies. Like we talked about, he doesn't really write tests for some of his side projects. But like, you know, if you manage your code in that way. I think, I mean, I don't need to justify not writing tests in a side project. But, you know, I think it would help me from not feeling overwhelmed, which is usually a blocker or a stopper for me, with my side projects.

[00:44:20] Jerome: And thomas, I think we've already also kind of done that, which is really affirming to Kofi's point with this podcast. I remember when we were starting this thing, we kind of, you know, took it not as like a Lark, but we really wanted to focus only on the interesting bits. And we tried to cut away all of the logistics and really just trying to focus on what do we enjoy, what do we enjoy doing? And yeah, like I said, I think that just highlights again, the truth behind what Kofi was saying and the insight that he had there.

[00:44:55] Thomas: Yeah. He's really tapped into something.

[00:44:57] Jerome: Yeah. Yeah, for sure.

[00:45:00] Thomas: Awesome. Well, I love this like meta commentary on the podcast and yeah, we're several episodes in and it's feeling more and more exciting every time we get to talk to someone awesome, like Kofi. So, I can't wait to see who we talk to next.

Thank you so much for listening to this episode of Collaborative Craft.

[00:45:26] Jerome: Check out the show notes for a link to this episode's transcript, and to learn more about our guest.

[00:45:30] Thomas: Collaborative Craft is brought to you by 8th Light and produced by our friends at Dante32.

[00:45:36] Jerome: 8th Light is a software consultancy dedicated to increasing the quality of software in the world by partnering with our clients to deliver custom solutions to ambitious projects.

[00:45:46] Thomas: To learn more about 8th Light and how we can help you grow your software development and design capabilities, visit our website at 8thlight.com.

[00:45:54] Jerome: Thanks again for listening. And don't forget to subscribe to Collaborative Craft wherever you get your podcasts.

[00:46:01] Thomas: You can also follow us on Twitter at @CollabCraftPod to join in the conversation and let us know who you'd like to hear from next.

[00:46:08] Jerome: We'd love to hear from you.

[00:46:10] Thomas: Bye.