(review this episode on iTunes)

Jud Valeski was co-founder of Gnip (acquired by Twitter), a real-time data portability software initiative. From client-side consumer facing products, to large scale back-end infrastructure projects, he has enjoyed working with technology for over twenty years. He’s been a part of engineering, product, and M&A teams at IBM, Netscape, onebox.com, and AOL. He has played a central role in the release of a wide range of products used by tens of millions of users worldwide.

Find Jud on twitter at @jvaleski and at http://one.valeski.org/.

Don’t miss out on future episodes! Subscribe quickly at StartupCTO.io/subscribe.

Episode Transcript:


FEMALE VOICE: Welcome to StartupCTO.io. The podcast where Miles Matthias and Kevin Owocki interview engineering leaders about management, startups, and software. Because your CS degree didn’t teach you to lead. And now, StartupCTO.io.

KEVIN OWOCKI: Hi. Welcome to this week’s episode. I’m your host, Kevin Owocki, and I’m here with my cohost, Miles Matthias.


KEVIN: This week, our interviewee is Jud Valeski. Jud Valeski is CTO of Techstars and has been a CTO in the Boulder area and investor for the last several decades. Welcome, Jud.

JUD VALESKI: Uh, thanks. Nice to be here.

KEVIN: Yeah, good to have you on the show.

JUD: Thanks.

KEVIN: Can you kick us off by telling us a little bit about your career in the Boulder community?

JUD: Yeah. My family moved to Boulder in 1979 so I’ve been here most of my life. All of the stuff I can remember, at least. You know, schooled through here. I went to the University of Colorado; studied Computer Science there. Graduated. Wound up in a program and position at Netscape Communications working on the browser side in C/C++, protocol implementation stuff. Moved up to the Bay area for four years to do that. Moved back here in 1999. Continued on through that writing software as an individual contributor on the client side; started migrating to the backend server side; infrastructure as well as managing teams. AOL bought Netscape along the way. I was conveniently located in the middle of the country so I flew around to both coasts to manage the integration of the Netscape Gecko browser engine and a variety of AOL products.

KEVIN: Awesome.

JUD: In mid-2000s, I left that role and around then is when I kind of describe Boulder’s startup community as kicking off. Software startup community to be clear – hardware has been here forever.

KEVIN: Right.

JUD: But, on the software side mid-2000s, Boulder’s startup community really kicked off in earnest in my opinion. Capital moved in in a real manner. A lot of creativity moved in.

KEVIN: That’s around when Techstars was founded.

JUD: Techstars was founded, right. You have a handful of things and another key contributor was Google purchasing a company called At Last. That showed a big strong software interest spending real money in the community here for acquisitions. Around mid-2000 everything in my mind started lighting up. That’s when I left my big company job at AOL to plant my feet down here in Boulder by the end of the startup space.

KEVIN: I noticed the first company you worked in the Boulder software startup space was Medium. Your title there was Director of Product Management. I know you were doing C++ programming and backend programming to sort of the more artful side of things.

JUD: Product definitions side of things. Yeah. I had started that arc at AOL kind of bleeding more into the product definition side of things. Yes, at Medium, I was much more focused directly on product definition and the “what” we want to build, not necessarily the “how” to build it.

KEVIN: Got it. Then your next gig was as CTO of Gnip which if people are familiar with the Boulder scene will be familiar with it through its founding and eventual acquisition by Twitter. How did your experiences sort of inform your role as CTO of and founding member of Gnip’s Executive Team?

JUD: Good question. In that capacity, I was bringing the technology to the table for the company. Me and my cofounder, Eric Marcoullier. He was more of the business end and I was more of the technical end. I mean, all my years prior had formed my approach and thinking around how I wanted to build software at Gnip. From a significant senior developer slant on the software to digging in and trying to solve real technical and algorithmic problems as opposed to just building an app. We were doing some actual computer science in there. Applying creativity to do that to build an interesting product that we thought the market was going to need. We had in terms of timing as many startups are. It was about building a crew – a creative and technical and scientific crew – and blending all that together to build interesting, highly scalable software.

KEVIN: It sounds like along the way, you were pretty intentional about how you built that culture. Could you tell us a little bit about that?

JUD: Yeah. Yeah. I have a lot of perspective around that. A lot of it is rooted in something very impersonal, but becomes very personal. I view technical folks – engineers – in a lot of ways. One view of that resource on the team is it is the most expensive thing in the room, bar none. Often more expensive than the executive leadership team. So you have to be very careful about who you assemble and rally to be on that team. A lot of care goes into ensuring technical capability and creative skill and creative capability around the approach to solving problems and approach to solving issues in the software. A lot care. That’s typical. We all put care into how we’re building the team. Once that starts to congeal, the challenge then becomes deployment of that resource. Because it’s the most expensive thing in the room. If you screw up the understanding of what it’s trying to build, you are wasting some untold sums of money. Startups die every day because of this problem. There is an intense focus on ensuring the right degree of definition and what the company wants to build. Such that these expensive resources that you’ve pulled together on your team can apply their technical capability as well as their creativity to solving the problem.

KEVIN: Right.

JUD: If you’re too overbearing with definition as a leader or product manager or what have you – whoever is defining the “what” – you are quelching this resource. This very expensive resource. Some startups take that route. They believe the leadership or the product leaders in the company believe they know exactly what they want to build, and then they go hire engineers that lack creativity. An engineer that lacks creativity is relatively inexpensive. You can save budget by hiring “cheaper engineers,” but you lose that critical component of creativity that blends technical skill and capability with exploration of the product you are trying to build. That is not a methodology I subscribe to. I don’t believe product people can answer all the questions around what a product is supposed to look and feel like and how it’s supposed to behave. There is this bridging between a general use case that’s trying to be solved and empowering and enabling this creative scientist in actually going to try to solve the problems. All systems and all framework in my mind goes into constructing the team and the value system around precisely that. No one in the room can lose sight of the value of these individuals. In a nutshell, my perspective has always been creative engineers are the kings of the world.

KEVIN: So, if I was an engineer on your team at Gnip, it sounds like it would be safe to say, I would have some scope around scoping the problem, defining the “what” we’re trying to build, and not just implementing requirements.

JUD: Absolutely. It is the product folks, in my mind, who spend most of their energy trying to figure out what the customer wants or needs. Lots of customer interaction and testing if you will of hypotheses. They construct a fair amount of definition, don’t get me wrong, but not all of it. When it gets down into the implementation details its hands off. We believe if we solve the specific use cases or user stories, we will win as a company. Now, help us build that software. I have no opinion whatsoever with respect to how I think we should build something. That’s the domain of engineering.

KEVIN: Is that hard for you to get to that point as a CTO who has spent 20 years building software at this point? I know that I would be tempted to see a “how”, and ask someone to justify it or to try to find my own experience. Is that an issue?

JUD: I’ve certainly come across and have spent a lot of time with people where that is very difficult. Undoing that in people is actually very hard when it’s there. For me, it was not hard. It was not hard because I’m just not all that smart. Everyone else in the room generally is much smarter than I am, and on the engineering side 99 times out of 100 that is the case. For me to suggest with any kind of vigor how something should be accomplished, there are very good odds I’m flat out wrong. I never carry with me this notion that I know better than the engineers sitting across from me or sitting in the room with me. When that’s your headspace it’s pretty darn easy. You literally really have to hand over the keys, if you will. Now, I do believe my intuition is often pretty good around direction, like technical direction. Are we heading in the right direction? That’s where I feel like I can contribute and ask questions. I may have a sense of let’s go this direction as opposed to this other direction. It’s pretty high-level. It does not go deep down into the implementation details. In my experience it’s yielded this pretty powerful combo. It is an acknowledgement that there are a lot of areas I have no idea what I am doing. A lot of people won’t do that. They truly do believe they have all the answers, which is delusional. They are invested in that, they believe in that, their reputation is on the line, but more often is the case, ego is so wrapped up in whatever role they are in they can’t see straight. You start to dictate the “how” – no, do it this way; this is the right path; do it this way; this new technology, this is new framework, it’s the bees knees; thou, shalt do it this way. That’s when stuff goes off the rails. I think I’ve often, particularly with technical stuff, my ego is in decent check so I’m able to let go of that.

KEVIN: How do you strike a balance between those high-level technical, architecture directional situations? How do you strike the balance between not dictating the how, and making sure engineers are capable of being on the right track? I know I have been in situations where I haven’t touched the code base and engineers are recommending a new direction and business wants to go in a completely different direction. It’s a very stressful position to be in. How do you strike the balance between not dictating the how, and still setting the right direction?

JUD: I fall back to the user stories that we are trying to solve. If they are being solved, then the “how” is less important. That’s not to say you can’t cobble something together that is not sustainable or software that only runs for 10 users when you need it to run for 10 million. Then, those user stories get blended into the mix. Ok, that’s nice, I see the solution you’re proposing or you’ve built to solve the use for 10 users, but let me add a user story which involves 10 million users or lots of users. You just keep refining the goal, if you will. You keep refining those user stories and tease it out that way. Over time, you may certainly realize, whoa, the problems we are trying to solve are outgunning our technical capability. That happens. You can find as your walking down the path you don’t have the right team in place. It happens all the time. As the business evolves, as the software evolves, as your customers evolve, you get into situations where you need to hire this other set of people. We need storage engineers, frontend engineers, but then that’s the responsibility of the team to understand and recognize.

KEVIN: Miles, I’ve sort of been dominating the questions. Do you have a couple or any feedback?

MILES: Oh, it’s ok. When you started Gnip, how many engineers were there?

JUD: Well, when we started we had contracted out a group called Pivotal Labs to build Rev One. We had myself and one other engineer on staff, full-time staff.

MILES: I guess I was going to ask in those days, were you doing a lot of hands-on coding then?

JUD: Yeah.

MILES: Ok. So then, how did you transition when you recruited a team from hands-on coder to more high level direction?

JUD: How did I transition from…

MILES: Was it a real natural process you didn’t think about or was it something you kind of had to be like we hired people now I should step away or now I should hand over the keys a little bit?

JUD: It was more the latter. Back to something I was getting at earlier, I was not delusional around the fact that I was not the smartest guy in the room. There was no “I must control this implementation.” Or, “I have the right way of doing this.” So, it was relatively straightforward in that regard. This is a key hiring component I think a lot of people screw up which is I was keenly focused on hiring people that were better and smarter than I was. That wasn’t in the job description, but it was implied. If you didn’t leave the interview room without me feeling like you could crush me, it was a no-go. A lot of people I think hire very differently from that. A lot of people interview for if I can control you. Are you good, but are you ever going to threaten me? If you are considering hires in that dynamic, your ship is sunk. You may be able to puddle along for a little while, but you will eventually sink. How arrogant to think that you actually have all those answers? It’s preposterous.

KEVIN: Another thing I’ve seen in that sort of scenario being in my mid-20s and trying to hire engineers is that if you don’t have great candidate flow and you don’t really know how to select great candidates, sometimes you make compromises that really jeopardize the long term team.

JUD: Sure.

MILES: I think that approach also gives you better candidates in the long run too because people are going to enjoy working with you and respect that you are going to hire people that are skillful and appreciate those skills and not just control.

JUD: Exactly.

KEVIN: Reputational stuff can kind of snowball.

JUD: Absolutely.

KEVIN: I’m sure you have great candidate flow at Techstars because of that.

JUD: You want that cycle to be going on its own.

MILES: So, you hire someone that is smarter than you and this is early days, you are hiring people that are smarter than you and you are wanting to hand the keys over because you guys are way smarter than me. Was that a difficult thing for you? Because I imagine that on some level in your mind you’re like I just hired this person. I am still kind of evaluating them. What was that process like? In your mind, is it like a three month thing? Did you think that you would evaluate that person and then hand them the keys? Or is it day one?

JUD: It’s certainly not day one. You have to know enough to be able to test that water. Day one would be a huge gamble. Some people have to do that. If you are a business guy and you have zero technical capability, you have no means by which to evaluate somebody. Then, it is a lot of guts and recommendations, check their referrals, hire and then go. In a lot of ways, the founding of Gnip was actually similar to that. It would be an interesting conversation with Eric Marcoullier, my business partner at the time. He had to do that. We’re going to come together and say, “Jud I’m going to trust you on the tech stuff.” He would crosscheck as best he could, but he could only go so far. But nonetheless, in general, there is some kind of trial period. Trial is the wrong word, but some sort of observation period. As it becomes clear what this person is capable of taking on, then you just let the rope out. That can vary from person to person. There are some folks, they come in the first week iteration and they blow it out of the water. It’s phenomenal work. It is quality work. It’s really moved everything forward. So, it’s like alright, here’s more rope. For other people, it’s slow growth – three months, six months. That is the role of the engineering lead for sure to understand where and how much rope they are letting out at any given moment.

MILES: That’s awesome. I think that’s a great point. I really love your approach around hiring engineers that are smarter than you. How do you maintain trust in relationships with engineers? A lot of engineers are all about the coding and the things that they work on. I think it’s really great to admit I hired you because you have this expertise. Is it just years of experience? No one wants to be like “I’m your boss.” That’s not a way to go in terms of relationship. Is it just like “hey, I’ve been doing this a long time?” Is that how you build respect and trust with those people? Or is it you have to have some level of capability and they are just smarter.

JUD: I think you have to have some for sure. That’s a huge component. For someone to just have people skills and do hiring and technical team construction and hope that executes, that’s a recipe for disaster in my mind. You have be able to hang in a deep conversation about caching and expiration and various endless technical topics. You have to be able to have that conversation and be able to empathize with the folks in the room. It comes down to that. It comes down to the ability empathize. So, when there is the user story we all agreed we want to take on this week, as we unravel that and get into the implementation, when Thursday rolls around and we’re way off in terms of timing and estimate, it’s critical that the engineering lead be able to empathize and understand that. Coming into the room with “well, you said this was going to be done on Friday and its Thursday and you are nowhere close” gets no one anywhere. This comes to another topic, which unless we want to I won’t go into it, but the punchline is for a technical company particularly a software company, but there may be exceptions on the hardware, for software company a CEO has to have had software in production in a reasonable manner at some point in their career. I fundamentally believe that.

KEVIN: Really?

JUD: If they have not pushed code into production and have users use it – whether or not they were successful at it or not, let’s set that aside for a moment – but if they have not gone through that lifecycle and that flow and that route, I do not believe they will be able to effectively empathize – whether it’s a two person company or a 100 person company – they will not be able to effectively empathize, back to the beginning of the conversation, with the most expensive resource in the room. If you can’t empathize with this thing you are giving all of your money to, you wind up in these horribly tense and misunderstood dynamics.

KEVIN: If they are just a resource, then why are they not getting anything done?

JUD: Exactly. I’m paying you tons of money, why aren’t you moving faster? I can’t pay you any more money. You should be moving really fast. There is no relationship whatsoever between the money I’m giving you and speed, yet, that’s often so confused. Unless leadership has written software, gotten it into production, and gotten it consumed by users, I think you can wind up with some pretty nasty operating environments and companies.

MILES: Absolutely. I can definitely speak to that at my current company our CEO has done exactly that so it’s really easy to empathize with us. One thing I was going to ask you and one of my last questions was just talking about Eric and the role of CEOs. Obviously, that is one aspect of what you look for in a business partner or a technical partner. Are there other things you look for in business partners?

JUD: I’ve gone through in the past almost 10-plus years now a couple of big business partner shifts – marriages, divorces, and such. I was in one with Marcoullier, and then my business partner ultimately at Gnip a guy by the name of Chris Moody who is still there crushing things. Those worked. I mean there were rough edges of course. When those were working, they were working because there was a relatively separate Venn diagram of who wanted to do what. There was little if any tension between the parties around what they wanted to accomplish. A very simple diagram is you’re a business guy; I’m a technical guy. I know nothing about business; you know nothing about technology. If we are good people and we have good rapport and we know what we are doing and we’re skilled that’s probably going to be a pretty good marriage. If as a technical guy I have a bunch of business aspirations, I want to be doing sales and marketing but that’s really your interest and your expertise, there is going to be inherent conflict there. It can be constructive and useful, but it can also be very destructive. If that Venn diagram in that partnership overlaps too much in terms of what each party wants to do, if there are ten things to do and we both want to be doing the same nine, it’s going to be tense. It’s going to be challenging. At the beginning of that marriage or partnership as best you can getting a feel for or an honest understanding of what both parties are interested in, ensuring there is not a ton of overlap there, is a good start.

KEVIN: That is actually a good segue into my next question. Jud, you’re an investor in town, what do you look for in teams that are looking to have you invest in their company particularly founding teams or markets?

JUD: What do I look for? I look for first and foremost the people, the team, the leadership team, passion, understanding, capability, desire. On the problem side, the problem that they are trying to solve there has got to be some kind of creative component. If it’s banging out yet another mobile app, don’t bother. There has to be some interesting software being written. Not an interesting business case that is being solved or an interesting flow that is being solved, but is there a piece of software in there that is doing something interesting. And does the person, the founder, know that? Sometimes they can’t articulate that or they don’t understand that.

KEVIN: So, you are looking for startups that are using software as a competitive advantage and a moving market? What do some of these companies look like?

JUD: There is very little relationship between one to the next. I would not say there is a theme at all other than what I just described. I believe these are strong people, very passionate in their approach and what they are trying to do. I guess that is one way to put it that they are trying to use the software as a competitive advantage. But again, it’s not some off-the-shelf app flow that they are trying to just apply to some business case. There has to be an interesting nugget in there. You can probably translate that to software as a competitive advantage sure.

KEVIN: I did want to ask you about a tagline I saw on your blog. It said something like “I love art and creativity, and I love technology and engineering, and I’ve made a career of blending the two.” Could you tell me a little bit about some of your hobbies and side projects in the more artistic realm and how that has informed your software?

JUD: Hm, interesting. Gosh. Many small software “in my office at home” projects – data mashup related stuff back when that was a thing ten plus years ago, scraping this, cobbling that API together, constructing some visualization around the data. A lot of data orientation on personal hobby stuff. Data collection or manipulation or visualization. That was a big impetus around Gnip was this explosion of public expression in structured digitized format. There is interesting stuff to do there. So, that was not unlike a lot of energy I had put into my world prior.

KEVIN: It sounds like you were working on those problems on a smaller scale, and Gnip was at a massive Twitter scale. I guess my original question about blending art and creativity, I know you’ve been meaning to frame that in the scope of software. For example, you are a photographer. There is a technical aspect to photography, but there is also composition. And I was just curious if anything like that really informed your software career.

JUD: Informed my software career. Sure. I think it’s a pretty literal blend in that context. An understanding of the processors and the sensors in the digital cameras that I use. Thinking about how light is going to hit this particular sensor that’s optimized for this color range or this speed or this resolution. That stuff goes through my head as I click the shutter. There is a new wave of mirrorless SLR-style cameras, which eliminates the ability to see the actual optical unscathed light on your retina through the viewfinder. I’ve rejected the whole wave of new mirrorless cameras because of this. Which is a funny counter to my technical side, but it is touches this analog creative side.

KEVIN: SLR has been around forever.

JUD: I can’t get away from an optical viewfinder. The notion of an LCD being the only thing I can view the light I’m trying to capture through is preposterous to me. There are phenomenal photographers that are mirrorless. The tech is awesome. I have a couple of mirrorless cameras. I use them sometimes, but when I’m trying to do something for real I have to drag out the big optical viewfinder DSLR.

KEVIN: One thing I think I’m learning is that you have this background in art and creativity and also technology and engineering. In the intersection that I’m hearing coming from you is a real taste and expertise in product design and how things are used. For me, blending those two things has helped me in what kind of technologies I want to use and what products I want to introduce into my life. So, it’s interesting to hear your progression there.

JUD: I haven’t spent time thinking about an answer to that question and how that stuff has impacted my view of software. I think as Moore’s Law shifts Intel has all but stated it’s not working anymore. That puts a lot of pressure on software construction. Maybe that’s one way to think about the blend. In physical hardware, in this case cameras, the game is shifting towards software. There is only so much we can do flipping the actual bits in the physical world. So the software we’re writing is only becoming that much more important.

KEVIN: You saw that in Apple’s announcement of the iPhone 7 Plus with what they’re doing with depth of field and the electro cameras.

MILES: Pretty soon you’re not even going to be using SLRs. It’ll just be your iPhone.

JUD: Conceivable. NASA has done some interesting stuff – I was talking with a buddy about this the other day – with hyperbolic lens shapes. We tend to think of a lens as a concave or convex semi-spherical shape. NASA with some telescope work they’ve been doing has been able to do some odd-shaped lenses that almost look like flowers, fluted flowers, to get similar focal lengths which would have required 10-feet before and now your down to a couple of feet with lots of weird light bending.

MILES: It’s pretty amazing.

KEVIN: Well, we could do a whole another episode on optical compressed ultrafast photography.

MILES: What strikes me about that balance of creativity and engineering, if you want engineers that are going to be creative and do that product exploration, it seems like having those other hobbies and creativity are super helpful?

KEVIN: Is that something you look for in hiring?

JUD: It’s awesome when it’s there. It’s not a requirement. There are phenomenally creative software developers that stereotypically actually do sit in their basement and write software. It’s incredible software. Little tiny external hobbies or forces there. I think it’s nice because I can empathize with that blend better, but it’s not a requirement. There are incredible minds sitting in chairs at a desk in an apartment.

KEVIN: I think we are getting towards the bottom of the hour. So I’m going to bring us home with our final questions, do you have any great engineering war stories that you would like to share?

JUD: War stories? I do. I’m trying to come up with them now. This is one I didn’t get to in the beginning in terms of preprocessing.

MILES: I have one about the Gnip website. I’m glad that we actually get to meet because I don’t know if you know this, but I used to work Digital Forge and helped build Gnip’s website. Gnip.com was on S3, and I didn’t know this at the time but S3 has a download limit. And, you guys made some big announcement.

JUD: Bandwidth or number of requests?

MILES: Number of requests per second. You guys made some big announcement and S3 reached the limit. And, S3 was just down. So, we threw a cloud front in front of it and it was fine from then on.

JUD: A traffic load problem. That’s good.

KEVIN: It’s a good problem to have.

JUD: Shoot. I want to answer this because I know I have good ones.

KEVIN: We can move on to another question and you can kind of keep that in the back of your mind. What are your engineering values?

JUD: Engineering values. Transparency and visibility into what you are up to. That’s not to management, that’s to your peers. Fluidity there. I’m hook, line, and sinker on pair programming. It’s a lot easier said than done so I don’t mandate it for myself or anybody else. But when it’s happening, the best software I have ever seen written has been written that way. I value that highly collaborative willingness on the part of folks. Similarly, willing and able to admit defeat when there is something wrong. Certainly, I’ve seen lots of software get written and just wrapped around itself and another week goes by and another week goes by. Almost there, almost there. And, you’re not. And, it’s because you weren’t able to stand up and raise your hand and say I’m in trouble or I botched this or this thing’s wrong, help me out. It’s again rooted back to collaboration, I guess. What else could I say there?

KEVIN: Creativity?

JUD: I mean, yeah, implied. Related to not just cracking open a textbook or some learning you had and applying just the science. A constant new hopefully creative view into how you’re solving a problem. Definitely important.

KEVIN: Shall we revisit our previous question, any engineering war stories come to mind? I mean, you guys worked with Twitter scale volume of data at Gnip. I’m imagining you guys got pretty good at load testing, and it’s a testament to your technical abilities that you can’t come up with something on the spot.

JUD: Now, this sounds very…, but it’s not me speaking, it is me speaking for the team. We did a lot of shit right. We did a lot great work there. There was a lot of rinse and repeat going on, and we built a lot of good stuff. One comes to mind and I don’t know if it’s a war story or not, but I think it’s a funny story. We had lots of people coming to us “wanting the firehose”. It kind of internally became this running joke because no one really had any idea what that meant. You still have prospects show up at your front door wanting that. Well, do you know what that means? Do you know how much data that is? Do you know how you would process it? Oh yeah, yeah, yeah, no problem. That actually often was not the case. People actually had no idea what they were in for. We did one deal. We did the deal, held up our end of the bargain all the way, but then, the customer went to implement and their ISP couldn’t handle the traffic. It took a week or two to figure out what was going on, and they figured that out and they got a better pipe into the machine. Then, their engineers didn’t know how to write asynchronously processing event handling type software, and couldn’t deal with the volume that was coming and queuing into their applications. They couldn’t process the data coming in. There was this funny moment where engineering on our end had to interact with sales on our end around qualifying customers. As a startup, if you get into a revenue world, hopefully you do, you have to be able to qualify your prospect’s or customer’s capability to actually pay. What is a qualified lead versus non-qualified lead? Often there is a revenue component to that. A part of that algorithm our sales guys had to start using was you have to run a test. Before we can continue the conversation, you need to run a test on certain products. We had certain products that were incredibly high volume. They had to run the test to essentially prove they could write software that could consume the product we were about to give them. Because obviously the horrible dynamic is you make the sale and then six months later the customer comes back to you and says I can’t do anything with this.

KEVIN: Right. I can’t get value out of this.

JUD: Even if you are doing it. Even if you are holding up your end of the bargain. I don’t know if it’s a war story or not, but it’s a funny technical scenario where the other party got themselves into this jam despite the demand for the product. It’s just kind of funny.

MILES: So, what did that test look like? You don’t have to get too specific, but was it just a huge fake data file?

JUD: No. It wound up being just a temporary slice of the stream that they would ultimately pay for. But, they had to go through this checklist on their end – you were able to get to it, check; you were able to get the data rate through, check; were you able to actually process the data? The third one was real software. To handle lots of messages coming in on one thread or in process and managing them in another is a small step, but it’s a crucial step. Asynchronous processing is a step. Surprisingly, a lot of engineers don’t get. They think synchronous processing. They don’t understand message handling or event handling or multithreaded processing. With high volume data that’s got to be in your blood.

KEVIN: Absolutely. I think that was a great engineering war story. Thanks so much for being on the show.

JUD: My pleasure.

MILES: Where can people find you online?

JUD: Twitter is @jvaleski. Same on Instagram. My blog is one.valeski.org. I blog about all kinds of random stuff there.

KEVIN: As we all do. Cool. Awesome.

MILES: Thanks for being on our show.

JUD: Thanks, guys.

FEMALE VOICE: Thanks for listening. Find us at startupcto.io or on at Twitter @startupctoio. If you enjoyed the show, please leave us a review on iTunes, Google Play, Stitcher, or wherever you get your podcasts. See you next episode.