Alter Everything Podcast

A podcast about data science and analytics culture.
Alter Everything Podcast Survey

Be entered to win a prize while sharing your thoughts about our podcast.

Give your two cents here
The Expert Exam is now live online! Read about the specifics and what it took to bring it to life in the blog by our very own Elizabeth Bonnell!
Alteryx Alumni (Retired)

We're joined by Steve Ahlgren and Neil Ryan for a deep dive on software engineering in the analytics industry.









  • Strategies for tackling those bigger strategies
    • Test first (related to TDD)



  • Working with Ned Harding, CTO
    • Pragmatism trumps everything
    • "Simple is hard", "it's either easy or it's impossible"
    • Do you know what Designer tool Ned wrote in Solutions Center at an Inspire conference? Tweet at us with #AlterEverything if you know the answer. First correct answer gets community swag!


Community Picks








BRIAN 00:05 

Welcome to Alter Everything, a podcast about data and analytics culture. I'm Brian Oblinger, and I'll be your host. We're joined by Steve Ahlgren and Neil Ryan for a deep dive on software engineering in the analytics industry, seriously, like Mariana Trench levels of deepness. Enjoy. All right. Steve, Neil, how are you guys today? 

STEVE 00:28 

Doing great, Brian. Thanks for having me on. 

NEIL 00:30 

Yeah, same here. Excited to be on the show again. 

BRIAN 00:33 

Excellent, so we are here with Steve Ahlgren. I'll start with you, Steve. We actually talked to you back at Inspire on Episode 7, so if people want to go back and listen to that, you can check that out. I believe it starts around the 22-minute mark with you. So we'll give you a second here to kind of give your intro, talk a little bit about who you are, kind of where you come from, and where you fit in at Alteryx, but I was just going to say that on the last time we talked to you, you had talked about being a principal software engineer, Server, Kerberos, HDFS, Hadoop. I mean, the list goes on, but I'll pause here and let you kind of give the intro from your perspective. 

STEVE 01:14 

Yeah, I appreciate that, Brian. Yeah, my name's Steve Ahlgren. I am a principal engineer here at Alteryx, and my six-year anniversary of the company was actually this past Monday. And it's hard to believe it's been six years, but I joined in 2012 into what was then a small company. And here we are, and it just keeps growing and growing. And my role here is varied. When I started on board, we were writing then what would become the Server - so before Alteryx 8, which was our gallery release - and I spent most of my time here working on the back end of Server. And so the ability to run workflows and execute and schedules and all those things, that was kind of my [inaudible] for the first three or four years I was here, and I really enjoyed that, really, really hard work, a lot of interesting problems. Working in a multithreaded server environment, that was my first one, and then beyond that, like you said, Kerberos and Hadoop and Spark Direct and all sorts of interesting projects. 

BRIAN 02:11 

Great. Thanks, Steve. How about you, Neil? 

NEIL 02:14 

My four-year anniversary with Alteryx is coming up. I've also moved around to different things in my time here. I started out on the Content Engineering team, basically building macros so that we could add new tools to the product at a faster clip. I'm on the Community team now working with you, Brian, but yeah, I actually got an opportunity to work with Steve pretty early on. So a few a years ago, we started working on the HTML SDK, so part of what you can do with that is put nice interactive HTML interfaces on top of macros. And I think I was the first person to start messing around with that functionality, and as it turns out, Steve actually built that functionality. 

STEVE 03:12 

That's right. That was the Chromium Embedded Framework. I had neglected to mention that in my intro. That was a heck of a project, and conceptually, the project was taking the chromium engine - so the back end of, for example, the Chrome browser - and actually embedding it into Alteryx. And there were three real use cases for it. One was - Neil, you mentioned - interactive GUIs, and so the ability to write native Alteryx controls in HTML5. The second use case was for rendering so for things like highly-interactive visual output from our Predictive Suite, for example. In our Browse tool, we embedded the Chromium Interpreter, and all of a sudden, you have live JavaScript, HTML5 flying around in Alteryx. And then the other use case for it was the actual back end of the engine, the ability to write plug-ins in JavaScript, and these are native engine plug-ins. They run the same as any of our C++ or C# plug-ins, and the Chromium work, it was a hard project. It really was. One of the things I learned from that was the power of test-first development, and we can talk about that more later. But I did that project entirely test first, and by doing so, we actually were able to release it. I think it was Alteryx 9.5 or 9.6. Our Getting Started release was the first time Chromium surfaced, the first time the CEF surfaced into the wild, and we used it there for the welcome dialogue where we played videos for tutorials and whatnot. 

NEIL 04:36 

Yeah, and so soon after that, I started playing around with it, seeing if we could put some nicer interfaces on top of our SalesForce and Marketo tools, and yeah, that's when I got to work with Steve, one-on-one, a little bit. It was pretty fun. He's a pretty responsive guy. 

STEVE 04:56 

I appreciate that. Yeah, I tell you. I'll tell you. One of the highlights of, yeah, my six years here at Alteryx was related to that JavaScript engine. And I was at an Inspire in Boston, and there was a gentleman named [Ramnath?] who's no longer with us was working on the Predictive Suite. And he really pushed the limits of it, and seeing that first, it was a Paul Revere model, a network analysis model up on the live stage on the 120-foot-wide screen or whatever it was. That was a mind-blowing moment for me to see that work all just kind of materialize in front of the audience. That was a cool moment. 

BRIAN 05:32 

So I think that's some really great background. Before we move on to our topic set for today, I do have one more question, Steve, for you. Sometimes, we like to dig deep into our guests' lives and kind of understand who they are, and the thing that I notice most often about you is when I see you on the community, I think it's you in your avatar riding a unicycle. What's going on there? What's that all about? 

STEVE 05:56 

That is correct. Yeah, so I started riding and racing mountain bikes at the age of, I'll say, 13, 15, something like that, and I spent most of my life on a mountain bike in some way, shape, or form. And I switched to off-road unicycling, I would say, maybe 10 years ago now, and yeah, that picture, my avatar is a ride with the-- a ride with a group of guys in Moab. That was a fantastic weekend, and yes, off-road unicycling, if you like chaos, it's the perfect answer for people who like chaos because it's not about riding it; it's about planning when you're actually going to fall off and crash and how you're going to-- how you're going to manipulate that crash. 

BRIAN 06:35 

So let's move on to some of the big things. We've talked a little bit about some of the-- you gave us some good insights there into some of your big projects. Is there something that, in particular, you're really proud of from a technical or a project standpoint that you could kind of bring home for us, talk about the origin of it, how it got started. Kind of give us the journey through a really highly-technical project that you think is a great example of your work here and sort of what we're trying to do at Alteryx. 

STEVE 07:07 

Yeah, that's a great question, Brian. There's two that come to mind. So Alteryx 8 was our gallery release. That's where we released Server to the wild. We put it into the Alteryx Analytics Gallery. Alteryx 9 was our on-premise release, and the challenge we had there was taking Server, so this edifice known as Server, and moving that into a packageable and runnable by a standard installer so that somebody could install behind their firewall and run with private data, with full security and whatnot, and one of the requirements there was to make it work out of the box with a single click. And with that requirement, it meant we had to devise a way to create Mongo on the fly, so Mongo's our back end database. And a fun project I had was actually writing the kind of the self-bootstrapping Mongo instance, and so when you run Server for the first time, if we don't yet have a database, we actually create one on the fly. And we generate users, and we generate credentials. And we store it all, and having that functionality not only allows the users to run the installer and basically kick up a server instantly, but it also allowed me to write regression tests really easily for the back end of Server. And so it was kind of a-- it was kind of a one-two, double whammy coming up with that functionality because it enabled me then for the back end, for our testing suites to kick up servers willy-nilly. I can have four or five running at any one time and have full interaction and full control over it, so that's one. That was a really cool piece of functionality that I got to create. 

STEVE 08:38 

The second one I'll shout out was something we called Spark Direct, which we just released this past year into GA, and that started as a project. And no snickering but it actually started as a design proposal called Project Woodshed, which I may or may not have written on a laptop in my woodshed at home, and what that was about was asking the question of, how do we control Spark? How do we actually connect Alteryx to Spark efficiently and kind of take away some of the mystery that is Apache Spark? It's big, difficult to use. It requires a lot of programming. It requires expertise. It requires a lot of kind of jiggery-pokery around data movement and whatnot. How do we make that easy to use? And so Woodshed was a proposal to make Alteryx the orchestrator of Apache Spark, and out of that, born a new team that we called the Emerging Capabilities team. And that was a team of one. That was me, and then, fortunately, Gary Schwartz joined on - another one of our kind of longer-termed employees here - and we trundled forward with this idea. And I'll be honest with you; I knew it had to work. I knew it just had to work at some point, and we kind of just moved into the wild and figured out how to install, how to better bootstrap systems with Apache Spark on it and learn all about the back end, learn about monitoring, learn about the file system, HDFS and whatnot, and, eventually, learn how to use Alteryx to basically commit Alteryx code to the server, run it on the server, and get the results back. And the culmination of that project, for me, was Inspire last year in the UK where I got a chance to be a part of the keynote, and that was a trip of just being up on stage and just talking about this functionality that had been birthed and created by a very small, dedicated team. And so those are two things that I'll call out. 

NEIL 10:31 

So yeah, I was just thinking of that London keynote because I remember watching it. How long was it from when you sat down or when you may or may not have sat down in your woodshed and started typing that out to when you delivered that keynote demo? 

STEVE 10:51 

That's a great question, Neil. I would have to look at the dates on the proposal. I think it was probably about a year and a half or so. I'm going to guess. Yeah. 

NEIL 11:02 

They're some big projects because that was a pretty big, complicated project that took over a year to go from conception to implementation, and then the one you were talking about earlier, CEF, that one took a while too, didn't it? 

STEVE 11:17 

It did. Yeah, CEF, I think I started-- again, I don't remember the dates, but we cut the 9.6 release in the spring. And CEF started sometime that late fall or winter beforehand. We were still in the Boulder office at the time, and my business card still says the Boulder office. But yeah, that was probably a 6-to-10-month project. I don't remember exactly off the top of my head. One of the fun things about my position is I've had a chance not only to work on the big, nasty problems but also to tag in on smaller ones so things like, "How do we integrate with Kerberos?", for example, in our HDFS I/O or the HDFS I/O itself, the ability to read and write files from HDFS. I did that as kind of a last-minute project, kind of a late-stage project, I'll say, and I was very happy to see that show up in the Inspire keynote as well. I want to say that might've been Phoenix or the year after. I don't remember. So a lot of these long-term projects we have-- it's a challenge being a developer. You have these longer-term projects, something like CEF or Spark Direct, and you're also getting pulled in on things like Kerberos and things like runtime settings and things like even client support sometimes. And so you're always context switching, and because of that, sometimes, project timelines drag out longer than we really want them to. 

NEIL 12:38 

Yeah, I was just going to ask, for some of those bigger projects, what are some of the strategies to tackle those? So I think it was in the context of the CEF project, before you mentioned test first, and I wonder if that helps keep those big projects in line. Part of the reason I'm asking is just because I don't know how much of our-- how many of our listeners are software developers, but I think a lot of them are Alteryx developers. And I would think that a lot of these same strategies might help with Alteryx development as well. 

STEVE 13:15 

Yeah, I agree. I agree. It's a great question. When you're given a blank slate-- let's take Apache Spark Direct, for example. You're given a blank slate, and you have this end goal. What I try to do is conceptualize, so I'm a structural geologist. My background is in structural geology. I also have a degree in computer science, and so what I try to do is draw it in crayon. And if I can draw a problem in crayon and just see a path through and if I can do that, then what it allows me to do is to start to prioritize based on risk. What's my highest risk on this crayon drawing? And that's where I'll usually start, and so for something like Apache Spark Direct, after drawing out the game plan in crayon, the highest-risk items were things like, "Well, what's the communication factor? How are we going to talk to it? How do we find a library or write the library that we need to use to actually communicate with Spark?" 

STEVE 14:15 

And once I have that in place, that conceptual model, I'll often drop into really simple modeling drawings, so if you've ever seen my desk, it's just covered with scrap paper and drawings. I'm a very visual person, and what I can take from those drawings is where I need to start, where I need to start writing tests. And so when I'm having a lousy day - I tell you - what I do is I start writing tests because writing tests, for me, it tells me what I need to think about next, if that make sense. And so by gaining these little toeholds, you start with your highest-priority items. You gain a little toehold. You write a little bit of test code, and you say, "Yeah, I think this is going to work." Those islands kind of meld together to form larger landmasses of tested code, and the island analogy, by the way, comes from a guy named Michael Feathers. It's not mine, but what I like about it is no matter what the project you're working, either a greenfield project or a legacy code or refactoring an Alteryx module, if you keep it in our mind that you're working in little pockets, these little islands and the goal is to connect those islands into bigger landmasses, it can help. It helps me a lot to steer through bigger, nastier problems by decomposing them into smaller bits. 

BRIAN 15:28 

Yeah, I think that's a key insight. I think, to Neil's point, probably some portion of our audience are the developer type, but I bet a lot aren't, right? And I think figuring out how to distill down these complex problems into manageable pieces, to your point, that you can sort of build on and connect the dots and put together like a puzzle is a really important skill for everybody to learn no matter what you're doing in life, right? I think that's really valuable advice, so I think that's really something people could take away from this. And also, we'd love a picture of your desk for the show notes so that we can show people the "controlled chaos" that you're describing here. 

STEVE 16:07 

I will definitely share that, and Brian, I appreciate what you just said. I do think that, as a technique-- we think about an Alteryx module. You're building out a really big, complex Alteryx module. Where I start is I drop in a text-input tool, and so a text-input tool, for me, is analogous to what we call a testing seam or a seam-in-code where it's a place where I can break the logic flow. And if you can find a break and you can use a little bit of dummy data or a little bit of dummy input and proof out an algorithm after that or before that, whatever it is, when you find those seams, those seams are critical for not even decomposing a problem but recomposing it when you have all the pieces. And so, Alteryx workflow is I write a lot like I do code. I treat them as kind of a continuum where I'll start writing a workflow, and as soon as something gets-- I'll start writing a workflow using text-input tools and using test tools all over the place for kind of test-driven development style, but as it gets too big, I'll start decomposing it into macros. So okay. I can do an extract method here. I can do an extract macro and break the workflow apart, so it's really about kind of building-- in my mind, building software is very-- and building an Alteryx workflow, you're building it up, and then you're breaking it back down. And as you break it back down, you're increasing the abstraction, which means you get reuse as well. 

BRIAN 17:28 

The other question I wanted to ask you about because you're sort of tickling my brain here a little bit with this is from a-- you talked about Woodshed, for example, which was you in a woodshed doing this work. Talk to me a little bit about, what's the difference in doing something like that from a singular, "Steve's out in the shed writing this" perspective to "Hey, I'm working on a team of people now"? What are those differences in your mind, and how do you approach those things differently? Or do you approach them differently? 

STEVE 18:01 

Yeah, I approach them very differently, and just to be clear, the Woodshed was just the doc. That was the design proposal. I tend to do most of my work at a desk, but when I'm working solo or in a peer-programming environment-- for example, when Gary and I started the EmCap team, the Emerging Capabilities team, we did a lot of peer programming, and just to back up, I mean, I've worked on a lot of different software teams. I've been doing this for almost 20 years, and I've seen different models, ranging from what we call the hero model, which is one person running off and writing something usually exceedingly complicated that nobody else understands, into kind of a full-team model where everybody's working collaboratively and pairing and kind of on the same page. And what I've learned is that the hero model tends to fail, and the reason it fails often is that someone will write this brilliant piece of code and then disappear. And two years later, five years later, folks come back in, and they don't understand it. And it ends up being rewritten or thrown away, and in Lean, we call that muda; that's waste. It's just wasted effort. 

STEVE 19:06 

And so one of my goals when I was starting a project is to write as much production-quality code as I can while also upscaling around. And so through mentorship, through things like peer programming, through code reviews, through one-on-one mentorship, you gain resiliency in the system because then more than one person knows the code base. I'm sure you've heard of the bus test or the beer-truck test. If you walk out in the middle of the street and get hit by a bus, what happens to the source code? And it's an unfortunate reality at a lot of companies that I've been at and just in the world now that if one of the key developers gets hit by a bus, a lot of that technology kind of goes away. And so when I'm scaling up into a team environment, it really is about trying to scale laterally, trying to empower folks on the team to take control of the code, and with Emerging Capabilities, the team that we did Spark Direct on or Apache Spark Direct, it started with just me and then Gary, the two of us, and then our inner mantra, our goal there, was to really scale the team. We brought three or four other people onto the team, worked with them, and by scaling laterally across a team, you gain resiliency. You gain redundancy in the system, so it is a different method. There's an old mantra in Agile - well, I guess just in programming - which is "You have to slow down to go fast," and by peer programming and doing code reviews and doing that mentorship, you have to slow down a lot. But at the same time, you gain speed because then more folks can understand the code, take ownership of it and maintain it and enhance it in the future. 

BRIAN 20:41 

I appreciate what you just said. I will tell you that I vastly prefer my version of the story where you're just out in a shed writing it, so we'll see if I do some editing magic to make my story the official story. But I also want to throw it to Neil here, and Neil, what are your perspectives on that? And maybe give us some insights into some of the things you've worked on and how you've approached it along the same lines of what Steve just discussed there. 

NEIL 21:11 

Yeah, so Steve's even more of a veteran than I am. He's been here, he said, for over six years, but just in my four years here, we've grown so much. It's crazy. You have to adapt your work style and your processes to be more team oriented or else it's just not going to work with all these new people. You have to figure out ways to ramp them up more quickly than maybe we were used to before when we were a smaller company, so it's been really interesting. It's been challenging too, but it's fun to try to see what bigger companies out there are doing to overcome these challenges and then adapt them to make sure they fit into our culture here because we still have this kind of start-up culture because, I think, it's more fun that way. So it's a challenge, but it's a fun challenge. 

NEIL 22:19 

Steve's been giving us a pretty cool peek behind the curtain to see how our engineering teams work together. One thing I was curious about is, how does engineering use Alteryx? Because you were talking about, "when I develop workflow," so obviously, you use the product yourself. I think every team at Alteryx uses Designer at least if not some of our other products. I know in the Community team, we use it heavily to automate kind of behind-the-scenes things with our community platform, moving posts around in bulk, things like that. Does Engineering use Alteryx Designer heavily, Steve? 

STEVE 23:07 

Yeah, absolutely, and again, backstory, I'm a longtime programmer. I joked that my favorite language is Pearl, but I dream in C++, and when I joined the company, Ned Harding, our CTO, within a week of joining the company, he said, "You need to stop using Pearl. Start using Alteryx." And I did, and what I realized is that anything I could do in Pearl or Python - replace that with any scripting language - I can do inside Alteryx. And I think about the use cases that I've had over the years. A lot of stuff around Server, for example, benchmarking Server, there's that blog post up on Community - I think I wrote it in 2015 or so - about benchmarking Server, which is not a conceptually-difficult problem, but if you were to write that code by hand, think about how unmaintainable it would be. And as Alteryx workflow with a bunch of macros, it's trivial. Really powerful stuff, recently, we had some client-support challenges around or not challenges, good, hard problem - I'll use that phrase instead - around migrating Server databases, and that, again, is a really hard problem to solve, reading and writing Mongo at the low level because we store things in these binary BLOBs, these opaque BLOBs that the internal format is not public. But using Alteryx, I could load the database, crack those BLOBs, manipulate at the bit level using or bit-twiddling tools in the Formula tool, and then rewrite it back out, and so we were able to successfully migrate at least one or two companies forward like that using Alteryx. 

STEVE 24:39 

Another great, concrete use case, recently, so I'm on a new team now whose name will remain unmentioned at the moment, but I'm on a new team the last six months or so. And one of the first things we did was decide, "Hey, we're going to reformat a code base," and so with any organic code base, over time, things kind of degrade. You get different styles. You get different developers. You get different rules kind of in play, different language constructs and whatnot, so over time, the code tends to diverge in terms of things like capitalization and variable naming and whatnot. And so actually, it's really not that hard using Alteryx and RegEx to replace huge swaths of patterns in code, automatically, and so you can think about it as a directory tool, dynamic input, formula tool or RegEx or whatever you're doing. And so we reformatted an entire code base. A lot of it was done inside Alteryx. So just actually this afternoon or this morning, I had to calculate some MD5s, and sure enough, BLOB-input tool, BLOB convert, and you get the MD5 out the other side in Alteryx. So it is the tool that I now use instead of using a scripting language, and so I'm a lot rustier at scripting these days. Don't tell anybody, but I don't write as much Bash or [KNOC?] or [OC?] or sed or Pearl or Python as I used to. Honestly, I just use Alteryx for everything now. 

NEIL 26:02 

And did you say bit-twiddling tools in the Formula tool? I'm not familiar with those expressions, bit twiddling. 

STEVE 26:09 

Yeah. Yeah. Yeah, if you open up the Formula tool, you can actually do things like logical ands and logical ors at the bit level, and if you looked-- and an extension of that, of course, is if you look at Alan Shen's recent post, there were three of them about building an ALU and building a CPU on top of Alteryx. So it adds [inaudible], these tiny little bit-twiddling algorithms, and because of that, you can actually use Alteryx to make an ALU, which I just think is wild. 

NEIL 26:35 

Steve, you brought up Ned before, our CTO. I've worked with him a little bit, but I imagine you've worked with him pretty closely. And I know he's got a bit of a cult following, especially at Inspires. He'll tend to hunker down in the Solutions Center all day and just work one-on-one with customers just like everybody else in the Solutions Center. I think a lot of the time, people don't even know they're talking to the CTO when they're getting help with how to build a workflow, but in keeping with our kind of behind-the-scenes engineering theme here, maybe you could talk a little bit about how Ned has worked with the team since you started. 

STEVE 27:23 

Yeah, I'd be happy to. I'll tell you the truth. One of the reasons I joined Alteryx six years-- so I came six years ago on a whim. It was a Sunday night, and I saw this Craigslist ad for a company named Alteryx. And I said, "Oh, why not? I'll apply," and when I met Ned and Linda and Rob and the team, I knew that this was the team I wanted to work with. And I've worked with a lot of talented developers in my career, and what really sets Ned apart for me was, as you've mentioned, Neil, is, number one, his humility. He will sit in the Solutions Center with anybody and just share his love of Alteryx. I mean, it's been his life for 20 years, right, since 1997, and one of the things that really struck me when I first met him was his quiet humility and confidence. But what really struck me was how he decomposes problems. He will look at any problem and see an end-to-end solution but not an end-to-end traceable, not just down the happy path, but all the fingers and the folks out there, and it's a talent that I haven't seen in a lot of developers. And it's one of the reasons I really wanted to work with him in particular, and I won't kid you. It's not all roses and unicorns. 

STEVE 28:40 

If he were here-- we butted heads a lot and for good reason. When I arrived at the company, I was really into kind of high-fluency, plus, plus, like really complicated structures and things like template metaprogramming and abstractions and really kind of pushing the boundaries of the language, and when I got to Alteryx, I was surprised to see our source code is really simple. And people would probably be shocked to hear that, but our core engine API, literally, it's seven or eight functions. And it's very straightforward code. I won't say the same for things like Calgary. You get into some of the details, and obviously, there's a lot of hidden complexity in there. But really, it's just conceptually-consistent code, and that's one of the things I really appreciate about Ned. And as we've worked together over the years, I find myself moving more in his direction, and so he has this quote that he shared with me early on. He likes to say, "Simple is hard," meaning that it's easy to make a complicated solution to a hard problem, but it's really difficult to make a simple solution to a hard problem. And I keep that. I have it on a Post-it note on my desk, actually, and I also have a second Ned quote that I really appreciate, which is, "It's either easy or it's impossible." And when you actually combine those two together, you kind of get this Ned paradox, right? Simple is hard, but it's either easy or it's impossible. So it's either hard or impossible, and I appreciate those thoughts because I carry them with me every day when I'm writing code. 

NEIL 30:16 

I was just going to say, didn't he give you some kind of challenge around writing code without tests or something at one point? 

STEVE 30:27 

He did. Yeah, that's a great point. I forgot about that, so when I came in, I was surprised to find fewer unit tests. We have extensive regression-test coverage. We use regression testing and test Alteryx every night, hundreds if not thousands of them, and when I started working on the Server project, I started writing unit tests, a lot of them. And there's a trade-off with unit testing. To do test-first-style development, you often have to change the code to fit the mold of-- to make it testable, and part of that carries complexity. And so Ned and I, we're always kind of going back and forth about, "Is it worth it? Is it worth the complexity?" And I'll say it was after the CEF project, and truth be told, I think Ned-- and he'll remember better than I, but I think he used one my of my APIs in CEF. And it was an API that I had kind of munged up a little bit, and he really didn't like that. And he was correct. It was accidental complexity to make it testable, and so he challenged me. 

STEVE 31:34 

He said, "Your next project, you need to not write test first," and so I did. And it was an eye-opener. It was a reminder that I still can write solid code without relying on the tests, but it was also a reminder about always being pragmatic. Pragmatism trumps everything, and with testing and test-room development, pragmatism gets lost sometimes. If you're following the rules and you're kind of doing it the way it's supposed to be done, sometimes, pragmatism gets thrown out to the wind, so again, as with my kind of overall coding style, going from more complicated to less complicated, I find, again, I'm in this gray area around testing. And I think Ned's really helped me to see that over the years. Ironically, the current work I'm doing right now, I'm trying to go back to test first just for fun because it's been a while since I've done that, so I'm really enjoying that right now. 

BRIAN 32:24 

I also do test first just for fun. 

STEVE 32:27 

I bet you do. 

BRIAN 32:31 

Great. Anything else before we move on to Community Picks that we wanted to touch on? 

STEVE 32:36 

Well, there's just one final-- yeah, I'll just throw it out there. You mentioned Ned in the Solutions Center, and I don't know if either of you know the answer, but can you name a tool that's currently shipped in Alteryx on the Alteryx Canvas that Ned actually wrote in the Solutions Center? On the spot. 

NEIL 32:53 

No, I don't know this story. 

STEVE 32:57 

Well, it sounds like-- and Brian, I'm sure that you'll have some free coffee mug or something, but it sounds like a "Send the answer in, and we'll pick someone at random to send a Community coffee mug," because I was there. He logged onto his machine. He remote-desktopped into his computer in Boulder and wrote a tool. It took probably about half an hour. 

BRIAN 33:14 

Okay, so let's do this. I'm totally down for this challenge, so if you're listening right now and you think you know the answer or you know the answer and you do not work at Alteryx-- I think it has to be a clear distinction here. If you are outside of the organization and you tweet at us using the hashtag AlterEverything and you are correct, I will indeed send you a Community swag bag. How about that? 

STEVE 33:38 

All right. Nice one. Nice one. 

NEIL 33:41 

Yeah, but I want to know now. 

STEVE 33:43 

I'm not going to tell you now. 

BRIAN 33:48 

Okay, so we've reached the Community Picks segment of the show. Steve, what has been interesting or awesome to you lately in the community? 

STEVE 33:56 

I've got to give a huge shout-out to the Weekly Challenges, and the reason being is that we just came out of Inspire season. I will be real and say the weeks before Inspire, what I do is I go pull down as many of those exercises as I can and I run through them just to remind myself the corners of the software. And also extremely impressed this year that the winner of the Grand Prix taught herself Alteryx by doing every Community exercise, so if folks aren't doing those exercises, it's a heck of a really easy way to learn the product. 

NEIL 34:24 

My pick is a Python contest that we're running on Community, a Python tool contest, so just recently with Alteryx 2018.2, we officially released the Python SDK. It's a way to create new Alteryx tools on the tool palette by writing a Python script, and so what we're doing with this challenge is customers can create a new tool, submit it to this challenge. And there's a opportunity to win a prize if your fellow community members upvote your tool the most. I picked this one. I thought this was kind of an interesting tie-in with Steve because, man, years ago, Steve did a Innovation Days project here at Alteryx where we get one or two days to work on anything we want, and he basically started working on that project. It was years ago, and it finally just came to fruition this year. And when I was product management, one of my passions is trying to get that project from a concept over the line, so it's fun to see that finally get out there. The contest may be over by the time this episode gets released. The contest ends July 31st, but even if it's past that date, it's worth visiting because it's turned into a little, mini repot of free Python tools that people are submitting and just sharing. So if you head that way, you might find a tool that's useful that you can just easily install into your Alteryx Designer. 

BRIAN 36:13 

And what is the prize, Neil? Let's hype this up a little bit. 

NEIL 36:18 

The prize is pretty cool. It's a custom mechanical keyboard that's tricked out with some Alteryx designs on there, so we also gave away the same keyboard to the winners of the Inspire Hack-a-thon, Alteryx Build, that just finished up in June. And they're enjoying it. The winners told me that they're clicking away on their Alteryx mechanical keyboard. 

BRIAN 36:48 

That's great, and maybe as a token of our appreciation for Steve for being on the show, we should get him one of those. He can put it in the woodshed and clack away out there. 

STEVE 36:59 

Keep the bears away, right? 

BRIAN 37:00 

That's right. They'll hear you coming. All right, so those are awesome picks. I agree wholeheartedly with both of them. The Weekly Challenges, I feel like we talk about these all the time. I spend so much time telling people how great the Weekly Challenges are because they're great, right? There are so many of them. I think at the time of recording this, there's over 120 - I want to say - or close to that, so the team puts these out like clockwork. They're amazing. A lot of them are fun. We try to have really interesting and fun subject matter so that it doesn't feel like work. It's a learning opportunity, and I think the biggest thing that I've noticed, observing the Weekly Challenges, is how so many different people have different approaches to the same problem. And I can imagine from a learning perspective, being able to see a broad range of 20, 30, 40 other solutions is really helpful to understand, "How do you compose a workflow? What are the efficiency options or decisions that you can make along the way?" So I totally agree with you on that, Steve. I think those a wonderful. 

STEVE 38:04 

Cool. Yeah, what you just said there about the many ways to achieve a goal, I mean, just to tie it back to my comments about Pearl and Python earlier, that fits in line with scripting and hacking. And Alteryx, to me, is just the ultimate hacking tool, so I think you mentioned there's over 120. I think there's 122 now, and I just noticed this morning, there's a new one about rabbits. And so you can model when the rabbits will take over the world is the newest challenge. I haven't done it yet, but I'm looking forward to trying that on the plane on Friday. 

BRIAN 38:34 

The one I always point people to is-- I think it's 82 or 83. It's a Pop-Tart and beer pairing, was a really cool one, and I tell people about this, and they sort of look at me funny, although that's a normal reaction to me in general. But once you go in there and you try those out, I think you see some cool stuff. 

STEVE 38:52 

Yeah, that's cool. I'll have to try that one too. I haven't done that one yet. 

BRIAN 38:55 

All right, and to round it out, my pick, actually, is you, Steve, so I'm going to put the links in the show notes to your blogs. I was reading up on some of your blogs in preparation for the show here. I understand at least 20% of what you've said in those blogs, but I have a feeling our audience will be much more technical and understand those things. I'm just kidding. They're great, and I learned a lot, actually, myself just reading them. So I wanted to point people to those, so we'll put the link to that in the show notes. Go read more of some of the wizardry of Steve there. 

STEVE 39:27 

I appreciate that, Brian. I always have two or three-- kind of the 80/20 rule applies to my blogs. I think I have two or three on my laptop at the 80% phase that I need to get over the line, but I'm going to be changing focus a little bit and looking more at Alteryx and IT and Alteryx and development. So some of the things we talked about today like how I use Alteryx, how developers use Alteryx, I think those are really cool topic matters for another set of blog posts, so stay tuned. 

BRIAN 39:53 

Excellent. Well, we will leave it there. I think that's a great place to end off, with a teaser to see more from Steve soon on the Community. Steve and Neil, thank you guys so much for being on. This was wonderful. I had fun. I hope you did too, and I'm really excited about putting this one out into the world for people to hear. 

STEVE 40:11 

Cool. I really appreciate the time. That was a lot of fun. Thank you both. 

NEIL 40:14 

Yeah. Thank you. 


This episode of Alter Everything was produced by Maddie Johannsen (@MaddieJ).

16 - Nebula
16 - Nebula

@BrianO @SteveA @NeilR These podcasts keep getting better and better! I really liked the 2 quotes ("Simple is hard", "it's either easy or it's impossible").