Russell Goldenberg

[00:00 - 00:06] So today we're talking to Russell Goldenberg. He's a senior journalist engineer with me at the Pudding, creating data-driven essays.

[00:07 - 00:18] If you haven't heard of the Pudding, you should definitely check them out at Pudding.cool. We make essays with data viz on really interesting topics.

[00:19 - 00:30] Yeah, I'd love to hear a little bit about how you got into the field, Russell. - I'll give you a medium version of the story because I can talk too long sometimes.

[00:31 - 00:47] But basically, my journey was I started out in computer science, so kind of a very traditional comp side track in undergrad. Decided that it was a little bit too technical and conceptual for me in a lot of ways once I got to the more advanced concepts.

[00:48 - 01:11] Happened to be taking some classes in like visual arts with some more programming explorations and stumbled upon the programming language processing when it was in its alpha phase. And that kind of keyed me into this other side of programming and doing more visually driven things and creative things.

[01:12 - 01:18] And I was much more into that. So that kind of changed my career trajectory into this field.

[01:19 - 01:34] I called it like creative coding or like kind of computational art. So I was very much following in the footsteps of people like Casey Rees and other people doing kind of artwork and installation work with computer programming.

[01:35 - 01:54] And that landed me at a job at the engagement lab at Emerson College where I was kind of doing a mixture of front end game development for civic engagement and also doing basically these games where we'd create them for communities and about social issues. But then we'd get a lot of data from it.

[01:55 - 02:01] And so that's when I started actually playing around with presenting that data. Having like no background in data visualization.

[02:02 - 02:21] So I was still kind of applying this visual art way of looking at data. And then really I didn't get into the true field of data visualization or data journalism until I went to open VizConf and I saw a reporter from the Boston Globe, Gabriel Florete.

[02:22 - 02:34] He spoke about basically how hard it was to do data design mobile. And it was a really interesting talk because I kind of realized this whole other challenge space of presenting information.

[02:35 - 02:43] And so yeah, I guess that's when I officially entered into data journalism and visualization. I applied for a job at the Globe after seeing that.

[02:44 - 02:48] And that's where it began for me. So there's kind of a meandering path just like that story just felt.

[02:49 - 02:55] Oh, that's interesting. I'd like to hear the long version, but we can't remember that.

[02:56 - 03:11] That's definitely an interesting path. How do you think your day to day is different than if you had kept on with the typical computer science career path?

[03:12 - 03:23] I feel like I much more likely would have ended up in like a software development firm or shop. I didn't even take any classes related to web development.

[03:24 - 03:31] And like my computer science track is very much like a, there's like one elect ive about it. So it wasn't even on my mind of doing anything on the web.

[03:32 - 03:47] And again, graphical programming was not something that was kind of big in undergraduate courses during the time. I feel like it's very different now the landscape of opportunity in the college world and obviously any type of online learning.

[03:48 - 03:54] So I feel like, yeah, I think the path was really narrow. So I probably wouldn't have ended up doing anything remotely similar to what I 'm doing now.

[03:55 - 04:03] And what does your day to day look like? Like how much do you spend coding or doing art like things?

[04:04 - 04:21] Yeah, I'd say about half my day is spent actually programming. I spend a fair bit of time just doing a lot of research and like around so, as you mentioned, we tell like all sorts of data driven stories at the pudding.

[04:22 - 04:41] The one I'm working on now, I'm looking at the usage of the word Oreo and cross word puzzles and why it's so common and kind of contextualizing that because there's a big corpus of crossword puzzle data that I've been playing with. So a lot of it is just kind of really steeping myself in this domain that I have no expertise in.

[04:42 - 04:52] I'm a very amateur cross-reposable player, but I don't know a lot about cross word puzzle construction. So a lot of it is just like doing background research, sometimes reaching out to experts and interviewing them.

[04:53 - 05:14] And then, yeah, the other half is kind of doing a lot of programming, putting together like mock-ups, writing the narrative for stories and kind of it's just a whole hodgepodge of kind of creative madness, I guess. I like to think that I could spend more than half my time coding, but it ends up being a lot of other stuff than just coding.

[05:15 - 05:20] Yeah, half the time, that's a lot though. Yeah, who knows if that's accurate?

[05:21 - 05:45] We should all do time tracking. One thing I think a lot of people run into that's hard when they start doing data is is if you get this new dataset, it's going to be in this field that you know nothing about and you're going to have to really quickly learn about the context and the field and everything that has to do with that dataset like crossword symbols.

[05:46 - 05:55] Do you have any tricks for doing that? And you usually want to do it quickly because you don't want to spend too much time just doing that research.

[05:56 - 06:50] Yeah, I think one of my self-pointed rules is like do it before I really get too far into the data because I feel like once you start playing with data or even exploring it, not even visualizing it, you start to just have assumptions about and things that you're like, okay, I now know what this thing is about, but you might have conceived it wrong all wrong if you didn't understand why that was the case. So I like to try to understand the context of the data before I even jump into it too much and then really I guess that's like one thing. I feel like another is I definitely will pause whenever I notice anything that 's like slightly amiss. So when I was doing this Oreo thing, I was like, oh cool, the first time they used Oreo as a brand was in 1993 even though we had data going back to the 40s.

[06:51 - 07:25] So like pretty much never accepting something, like kind of figuring out why that's the case rather than just accepting it and moving on. I think just like constantly questioning what you see because I have very suddenly, and that's only just like talking about the context of when they're saying the data set. I feel like lots of times more often than not, the thing I'll find is actually an issue with how the data was collected or put together. So I think just not having, not trusting the data is probably the biggest thing for me too. Yeah, very skeptical of mine said.

[07:26 - 07:33] Be very skeptical or yeah, be curious of why it's like that, not just, oh cool, that's what it says. Oh, weird. Okay.

[07:34 - 07:59] Yeah, that's awesome. And then what usually comes next in your process. So you look at the data, you understand some background, you kind of mine through it for anomalies or things that are interesting. Thanks. For me, I'm very visual. So I actually get to pencil and paper sketching really quickly.

[08:00 - 08:56] Usually I'll start thinking of really interesting ways to present it that are not necessarily even feasible with the data. I just like to get all the ideas down on paper because I think when they're in my head, they can seem too good to be true until I start sketching them out and kind of have to come to the, like, answer the hard questions. Like, oh wait, can I even do this thing that I'm sketching out? So I feel like for me, sketching a bunch of ideas in a really quick format is really helpful for me. So that's definitely something I do pretty early on in the process. Yeah, I really, I don't sketch much or like I don't like ever feel like sketch ing, but then once I do, it's just like really freeing because you can sketch anything, you know, but whereas if you're like iterating in code, I'm a really lazy developer, so I'm just going to do it easy.

[08:57 - 09:16] And like, it's not necessarily going to be the best visual. Yeah, I think you definitely can let your imagination run much more wild when near you can just spend 15 seconds sketching something rather than like, let me try to build this whole framework up and then realize, oops, like the data doesn't quite work or this isn't necessarily the best thing.

[09:17 - 09:25] Yeah, yeah, which can be really frustrating. Yes, I can. Okay, so you sketch and then do you go straight to the code?

[09:26 - 10:55] Most of the time, yes. So like, I, again, because I don't like seeing high fidelity stuff, I like to let it kind of be a little more emergent. It's very rare that the thing I set out to build is the thing that I end up building like when it's all said and done. So I find like bringing the iterative process kind of early on in my production phase much better than coming up with like a picture perfect mock up. Because then also I just feel like I'm beholden to it. If I there's this high fidelity mock up, then I'm like, oh, this is what I have to make, especially if I'm working like with somebody other than just myself, if I'm working with a collaborator or a client, I don't like to, it's hard to like set up that expectation. And then as you iterate, you're like, oh, we will actually want to go over here. But like, they're really expecting that thing. Yeah. So I definitely prefer to just kind of like iterate in the code and see what happens and just make adjustments along the way. So maybe not the, I don't think it's definitely not the most efficient way, but I find it uses the most, the results almost crowd of. Right, you have a meandering code path or project path, much like you have a meandering career path. Yes, they, they follow, yeah, they parallel each other, I guess. I don't like doing things to restrict in there, I guess. Just a personality tree.

[10:56 - 12:52] Has nothing to do with coding is about my personality. Speaking of coding, do you have any tips for people who are just getting started out with D3, which can be notoriously difficult to wrap your head around? Yeah, I think one tip is look at more than one source. So like pretty much everything I learned in D3 came from looking at other people's code. I feel like you can, like once you get the fundamentals and you understand like how to read the language, then you can actually like start looking at bigger pieces like, oh, how did someone actually put these two different concepts together or kind of looking beyond like the basics. And I think looking at other people's code is really great because it shows you the different things you can do with it, but also it can be terrifying because like personalities, everyone has very different coding styles and just ways of structuring it and thinking about solving a problem. So D3 is nice because it's super flexible, you can think it's very low level. But that means there's like eight different ways you can solve one problem. So I find the best thing to do is actually just try to look at a few different ways that multiple people have solved the problem because some might speak to me more or some might be organized better. So I think that's like a really important thing is don't just look at the first source of the thing you looked at. And that's like the truth and the way to do it because I think there's always a few different avenues. Yeah, I like that. And it kind of goes back to your simple point of like, like don't just look at one source and copy it. Don't just take this course and copy the code that we built and said like, stay curious about like, why are we doing this? Why would it be done this way? What other ways are people doing it? That kind of thing.

[12:53 - 13:10] Exactly. Yeah. I guess I have a little trust issues with data and other people. I think they're valid. And my last question that I wanted to ask you is what is your biggest motivation? Like what do you love the most about this kind of work that I keep see going?

[13:11 - 14:30] Um, it's a great question. I feel like I have a few motivations. I feel like seeing it's not maybe a competitive thing, but just seeing that the field is still kind of emerging and seeing how people tackle the problem of, you know, right, data visualization is commute like taking data and making people try to understand it visually. I think it's one of these things that there is like the simple way to do it, which people understand, but then there's like, how do you tell something that's like the more complicated nuanced ways of getting people to not just understand what's in the data, but like really, I guess like feel it and like, like kind of internalize it. And I feel like that's the thing that I see a lot of experimentation with in the field and seeing how other people like are constantly pushing that on both and trying out your things keeps me motivated because I'm like, okay, we haven't solved all the problems or seen everything yet. So like, I'm like, there's still like reasons to be creative with it and try new things out. So I think, yeah, that's it in a , in a not, not in a nutshell. But seeing what other people are seeing that other people are still kind of experimenting keeps me motivated. Yeah, yeah, same. I really like that.

[14:31 - 14:44] Yeah, thanks so much for coming on today. Really enjoyed talking and talking about how skeptical and meandering that you're approach to things is. Thank you for having me.