In this episode, we talk to Yodit Stanton and Martin Trojer about teams, startups and IoT.
The show is available on iTunes! You can also subscribe to the podcast using our podcast feed.
You can send feedback about the show to podcast@cognitect.com, or leave a comment here on the blog. Thanks for listening!
EPISODE COVER ART
AUDIO PRODUCTION
PRODUCER
Our theme music for this episode is Thumbs Up (for Rock N' Roll) by killthenoise with Feed Me which was used under a Creative Commons License.
In this episode, we talk to Yodit Stanton and Martin Trojer about teams, startups and IoT.
CRAIG: Hello, and welcome to Episode 110 of The Cognicast, a podcast by Cognitect, Inc. about software and the people who create it. I'm your host, Craig Andera.
Okay, announcements. Well, we have a few. Tickets are still available for EuroClojure, the Clojure/conj, and the training that happens immediately before the Clojure/conj. Just to remind you, EuroClojure will take place in Bratislava, Slovakia from October 25th to 26th, and the Conj is in Austin, Texas from December 1st through the 3rd. The training before the Conj will happen immediately before the one or two days before, depending on which of the various training options you're looking at doing. Go ahead and have a look at the websites for those. You can search for EuroClojure or search for Clojure/conj, you'll get right to the right place.
There is a Clojure users group meeting in Buenos Aires. That's happening Wednesday, September 28th at 7 o'clock at the Urban Station Palermo Soho. I'm not familiar with the area, but hopefully that means something to you. If you happen to be in or can get to Buenos Aires, go ahead and check that out.
There are still seats available for a couple of ClojureBridge workshops coming up. One is happening in London from September 30th to October 1st, and this is all, of course, in the year 2016. The other is happening in Boston October 14th and 15th. Find out more about that and all other things ClojureBridge related, including how to donate to support that organization, at ClojureBridge.org.
That's all I have for you in terms of announcements, so we'll go ahead and go on to Episode 110 of The Cognicast.
[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]
CRAIG: Fun. I'm looking forward to it. Okay, let's see. Yes, all good. Welcome, everybody. Today is Tuesday, August 30th, 2016, and this is The Cognicast. Today we have two guests with us. We're very pleased to welcome them both to the show. We have with us today Martin Trojer and Yodit Stanton. Welcome to the show, Martin and Yodit.
MARTIN: Thank you.
YODIT: Thank you.
CRAIG: It's really great to have you here. I think we have lots of interesting things we can talk about. You were both highly recommended to us by a couple people, but including Alex Miller who said, oh, you should definitely have this team on. But we'll get to that in a moment.
We are going to start off like we always do with a question about art. I think Yodit has either one or lost the coin toss as far as being the one that takes that question, however she wants to look at it. The question, of course, is about some experience of art, just something you'd like to share with us. It could be anything from a book you've read to any experience of art at all, whatever that means to you.
Since we did forewarn you about this question, I am assuming you have something prepared that you would like to share with us. What would that be, Yodit?
YODIT: Okay. I'm not into kind of painting art or anything like that, but I'm into medieval history and visiting places. One of the most interesting experiences I've had is I'm Ethiopian and, in northern Ethiopia, there is a placed called Lalibela, which is rock cut churches that were built in something like the 12th Century if not before. Within these churches there are many, many smaller churches as one big kind of – when you look at it, you actually can only see it properly from a helicopter or really kind of high above. You see this kind of cross cut into the rocks.
I just find people building these kind of structures, especially at a time when we necessarily didn't have the tools obviously, and also when you're building these kind of massive, massive structures, a lot of the people that are designing them don't actually – they don't end up, in their lifetime, seeing the fruit of their labor. Whereas in what we do, the fashion for tech changes nearly every six months, and it's hard to keep up. I kind of find that juxtaposition of different ways of people work interesting.
That's my input. Look it up. It's called Lalibela. It's in Ethiopia. It's amazing.
CRAIG: Hmm. You said it's rock cut. You mean it's actually carved out of a hill or a mountain rather than being built from blocks or something like that?
YODIT: Yes, so the structure is cut directly into the rock, but it's huge. It's massive. I don't know how many. I think there are about eight independent churches inside this massive one church, and it looks like it's just one big stone cut cross building, but it goes down–I don't know–a couple of floors, maybe three floors.
There are many monks that live within the nooks and crannies. They're kind of away from the world. Yeah, it's amazing. You walk inside of these churches, and it's just so many different types of paintings and all sorts. Yeah, it's very amazing.
CRAIG: It sounds absolutely fascinating. There are so many interesting places in the world to visit, but that definitely sounds like one of the – just it would be really cool. I suspect when you're standing in it, it's quite impressive as well.
YODIT: Yeah. It's fairly awe inspiring. I think it's kind of your – from when you're standing inside of it, you don't actually know that it's, well, it's not very obvious that the whole building is one big cross because it's that big. And it's a fairly – I haven't seen anything like it and I'm not really sure where the design comes from. Maybe they don't do it that often because it's probably really hard, but yes.
CRAIG: Mm-hmm. Cool.
YODIT: Very cool.
CRAIG: Awesome. Awesome. And I love the comparison with what we do as well. We will, of course, turn from that topic, as fascinating as it is, to topics more technical.
Maybe before we do that we should give the two of you a chance to introduce yourselves a bit to our listeners that may not have encountered you before. I think we'll throw it over to Martin and give him a chance to introduce himself. Martin, why don't you tell us a little bit about yourself?
MARTIN: Yeah, I'm Martin, a software developer, going at it for some while now, I think about two decades professionally. I lost a couple of years to management, but I'm back on track now writing code. First off, my career was a lot of embedded systems like low level real time operating systems, mobile phones and stuff. But I've been slowly working my way up on the hierarchy abstraction layers. Now I'm doing Web apps like everybody else.
CRAIG: Mm-hmm.
MARTIN: Backend, front-end, doing Clojure about five years professionally, so I'm well involved. I've been involved with a little bit of the London community here around Clojure, et cetera, so I'm enjoying it.
CRAIG: Yeah, and I should mention I see your name quite often in connection with the show. You're obviously a listener, for which we always appreciate.
MARTIN: Yeah, I've been enjoying the podcast for a long time, and I've been going to some Clojure conferences, et cetera, as well, and talked on a few, so yeah.
CRAIG: All right, awesome. Cool. Well, we will definitely be coming back to talk to you a lot more here in this roughly hour, but let's throw it over to Yodit and give her a chance to share with us a little bit about her background or really whatever you want to say about yourself.
YODIT: My name is Yodit. I've been professionally a software developer for probably about 15 years. I am, well, I was doing what's nowadays referred to as big data processing, but I started in investment banks, so I've been working in orchestrating kind of low latency systems pretty much from the start of my career, so moving lots of data around, presenting data, lots of real time kind of mission learning, which is modeling, financial transaction in Black Fox Trading.
I'm a Java–I don't know what to call it–I'm free of Java now, but my transition to Clojure has been coming at just being sick of Java having written in Java probably for a decade. I got into Clojure as a dabbler probably about four years ago, professionally more of about three years. Nowadays, for my sins, I run a startup called OpenSensors, which is kind of a lot of the stock is obviously in Clojure, as I'm sure we'll discuss at some point kind of the Clojure data processing, especially where we started when Hadoop was coming in. As in we, I mean generally kind of the data, the open source data world. Hadoop was just kind of early stage maturing. Clojure was just amazing to get stuck into the Hadoop world, so it's got a very loving space in my heart for Clojure, especially on the data side.
CRAIG: Yeah. Awesome. You mentioned the startup, and I actually want to dig into that a little bit. You were talking, of course, about OpenSensors.io, and maybe I should let you describe it, but I think we're going to talk a little bit about Internet of Things, which is actually a topic that I wouldn't mind exploring a little bit on its own. It's something that I haven't really done a lot of work in that area, but obviously it's something that is quite relevant, quite topical, a growing area. Maybe talk to us a little bit about the company, about Internet of Things more generally, and then, of course, we would love it if you would tie in how, you know, the technologies that we and our listeners enjoy–you mentioned Clojure, but of course there are others–how you've been able to make those work or maybe not work for you in that space.
YODIT: Sure. That's a very long tale, so I won't tell it by myself. I'll start with introductions and kind of talk about the early days, and we can talk about what we're doing now. The technology stack, because we've used Clojure from the start, has kind of evolved in a massive way.
Yeah, I should have introduced my startup. This was terrible of me.
CRAIG: You're just modest. That's all. You're just modest.
YODIT: Okay, or I'm not. Yeah. OpenSensors really is a cloud data infrastructure for the Internet of Things. The way it works is that people can process data from their sensors. They can plug in their sensors, manage their devices, kind of authenticate their devices and we process the data.
The interesting thing about it is that we also tell people if they have public data, they should share the data as open data. The way it's shared is with open data licensing, so it's very close in terms of structure and lots of things to open source, so anyone can take that data, reuse it, plug it into their own systems, and I suppose that's our very unique view of how IoT would even work or even scale because you supposedly have these billions of devices coming online over the next five years or whatever - pick a number.
What people don't really appreciate potentially is that managing these devices is hard, changing the batteries to kind of infrastructure management, as well as buying the sensors. It costs money. Why not, if it's public data, if it's things like air quality, water quality, why shouldn't people share it? That's been really successful over the last couple of years.
We've built up a community and people are actually creating their own communities these days where they have local sensory networks around air quality, water quality–I don't know–earthquakes, all this kind of stuff, and they're sharing the data. People are taking the data and reusing it in all sorts of weird and wonderful ways. It's actually fascinating to see. I guess that's what we're building in terms of the vision.
We're a Clojure shop. Yeah, I can go into that. Does that make sense?
CRAIG: No, totally. No, it's fascinating, actually. I mean it's fascinating on a number of dimensions. Certainly I think, socially, right? This idea that I could do great things if I could just have access to the data and building a platform that will give people access to the data is really, really interesting. I've often said that kind of one of my fantasies for the world would be that we are able to connect the people out there that have programming skills with the people out there that have problems to solve because I think a lot of us go around.
We write software to solve all of our little problems, like I'm playing a game and I think I'll write a thing to keep track of my scores. Well, wouldn't it be great if you could turn that towards solving a disease instead, even if it was only part of your time. Anyway, I feel like what you're talking about is, in some sense, in the same spirit of let's find a way to connect people with the resources that they need in order to do good things.
MARTIN: Yeah, I think so. I mean the analogy to open source is quite clear, right? You can imagine, like Yodit said, when all these millions of devices come online, what do we do with this core piece of data? How do we expose it if it's open? How do we categorize it? And how can communities come together and share data? If you are a community around a school or something and you're worried about traffic or air quality or whatever, we want to provide a platform where they can find data or, if there is a white patch on the map, somebody can get a sensor, stick it on their balcony, and kind of contribute, join, and get something out of it.
In the case of air quality where we've done a lot of work, you can see stuff like people who are running to work, commuting. That would be one example. They might be very interested in just tracking air quality and deciding, okay, I have to take the bus today because some smoke cloud has drifted in. Lifting and making all that data accessible is kind of what we're trying to do and just trying to create the platform for these communities, a place where they can come together and share data. And tell their stories as well, so this is a project and this is why we're doing it. Here's a way to kind of see what we're doing and highlight it.
CRAIG: I imagine the technical challenges are quite significant. First of all, I would imagine that there is the potential. I'm not sure where you're at right now, but there is at least a potential for just having absolutely enormous amounts of data. Maybe that's not even the biggest challenge you have, but is that a challenge? If that one is not big deal, what are the challenging parts of the problem you're trying to solve?
MARTIN: I think, technically, yes. There is definitely. People have been talking now for the last two or three years on how enormous this thing will be. I don't believe there will be one single winner who will take all the data. I think it will be partitioned off, but a lot of the sensor data is and will always be private, so they won't really be seen, and they will be handled by infrastructure providers like Amazon and everybody else just doing place into IoT now.
But yeah, I think, for us, ramping up, we have the kind of classic old startup problems. We have this vision on this community driven site, and it's just trying, trying new features, trying to make it as simple as possible to bring new sensors online because typically IoT, so IoT has been quite strong, like in the maker movement. People coming together with Arduino and building small robots. This is great, and we definitely have been part of that, especially in London. But this is highly technical use person if this is to really scale and if it's possible for normal people, if you will, to buy sensors and enable sensors. How do we make that slick, right?
I think that has been our key problem now just finding the right feature set and making it easier for people to come online and use it. If it grows, yeah, as I'm working a lot in the backend, obviously I think about those things, but there's only so much. At some point you have to stop thinking, worrying about it, and say, yeah, this is good enough for six months. Now let's focus on something else and revisit it if it's a problem.
It's kind of the normal kind of startup Web thing that might blow up, and then it's hard to predict exactly where things would break as well when they scale up, right? You don't really know until it happens.
CRAIG: Yeah, especially in a market that's, I mean, really pretty brand new.
YODIT: Yes, it's very nascent. That's the other thing is there is, first, I think the biggest discovery, we're probably kind of an old company compared to many others in the IoT space. It's still very nascent. There is no good way of doing things yet, and you're always trying to figure out what works and what is a good experience when you're kind of creating IoT services.
One of the most surprising things – and I think we've got, actually, quite far. I think we don't potentially, like, stop and think, wow, we've built all this stuff. We have kind of–I don't know–more than – I think we're more than 15 million daily messages processing at the moment. We have kind of communities mushrooming everywhere, and it's quite fascinating.
** The other thing that the kind of movement, the community movement has also created. The way we charge is, like, open data is free. Private**: people pay us. It's really the GitHub model. What we're seeing a lot is the private networks, sensor network deployers using the open data with their private networks because they're kind of realizing that they combine multiple data sets and they get better insight and they get better analytics.
We have two big problems or challenges. One is: How do we make it very easy to publish data from the sensors end-to-end and actually let people publish data and make it open? The other one is, well, how do we let people understand what's going on? If they start crunching different sensor types together, like people are crunching … data with weather data and they're trying to see if there's correlations and that kind of thing, how do we make that easier?
No one has done it before, so I think it's the more – I mean we've done probably, what, two or three iterations of the platform, both front and backend, and I suspect we'll do a number of iterations before we get it right because there is nothing to follow. We're kind of doing it, figuring it out, and that takes a lot of failing and a lot of kind of coming back again and really tweaking.
CRAIG: Sure. Yeah, so I'm really interested in this analogy. You mentioned the GitHub model, right? There's private data. There's open data. It makes me wonder how far the analogy goes. For instance, I wonder if you can compare kind of the qualities of private data versus the open data. Does it tend to have different characteristics around things like how much curation it needs or what parts of it people pay attention to? I think there are real significant social differences between maybe not so much like a private GitHub, but like commercially backed software and open source software. They just have different characteristics.
I'm sitting here going, I wonder if that's true with the data as well. Is there something about the fact that people are holding this themselves or circulating it under a smaller community that gives it visible characteristics that you can differentiate?
MARTIN: I think one of the differences, one of the things that's special with IoT, you know if you talk to people doing Web stuff, is there's actually hardware on the other end. There's really sensors and gateways talking to us. It's just not browsers and phones.
One difference is definitely in the quality of the sensors themselves. The open communities usually use kind of fairly cheap sensors on Arduino, et cetera. That quality surely differs from maybe private data where corporations can afford purpose built hardware with less noise, et cetera. That's definitely different.
I think in the way, if we think in a cleanliness of data, the thing is once you've written kind of the firmware for these sensors, they stay the same. That's one of the problems we want to solve. We want to help people to get it right from the beginning so we can categorize the data and make it explorable and searchable downstream. I think that one of the main problems, like I said, is made the difference in hardware, what people can afford. But once the data starts flowing, I don't think it's a massive difference. If we've done our job right and people find it easy to kind of categorize and tag their data so we can use it, it's quite on par.
YODIT: And also the quality has improved the more sensors you have. The density of the sensors matter. If you have lots of air quality sensors in the city, if you have lots on a street, for example, you have a better picture of what the baseline is. If you have one sensor in a whole neighborhood, then it's going to have to be an expensive, maybe scientific grade sensor, so the density of how you deploy matters.
MARTIN: Yeah, so the open source model works well then when everybody can. If you have a large corpus of cheap weather stations, you can, with some analysis on top of that, probably extract some real valuable analytics.
CRAIG: Interesting. You mentioned devices and how people are using small devices. I guess when I think about Internet of Things, I don't know whether cell phones play a big role or whether it's more focused on smaller devices. But it occurs to me that we all carry around devices with multiple sensors in them. My phone has air pressure, humidity, light, a camera, obviously, GPS, all that good stuff.
Is the fact that we all – maybe not all. That's a strong word – but so many of us have these devices with us. How much do you think that's going to play into this growing trend towards gathering data and being able to hopefully make use of it?
YODIT: Yeah, I think there's a lot of potential. There's a lot to be figured out in terms of privacy. I think that's the thing is like how. I'm quite excited about obviously all the data, gathering all the data and packaging it. But then I step back and think, oh, gosh, if I get the GPS location, even if it's anonymous, what is the potential of people? Obviously we all know that it's actually quite easy, with a few data points, to figure out who’s releasing that data, so I don't know.
I'm not conflicted on it. I think it's fine for certain use cases. Obviously people are using phones for beacon technology, which is indoor triangulation where a lot of retailers are kind of using. They give you an app. When you go near a particular scarf, they push a coupon or something. That kind of thing. There's definitely going to be a mass, I mean phones are going to be pretty central to a lot of the things we do, a lot of the trends that we're going to see over the next five to ten years.
On the open data side, I'm still thinking it through. Obviously on the open data side, we want public data. We want environmental data. But we don't particularly want to be the company that's going to violate everyone's privacy. So I don't know. What do you think, Martin?
MARTIN: Yeah, I agree. One of the key metrics for the data is the location, right? Pretty much anything you measure there, like air quality or temperature, we kind of need to attach a location. We support both kind of mobile sensors as it moves around in cars, or the fixed ones. But the problem is in tracking temperature and the air pressure on people's phones, you could, if you're not taking big steps on our side to kind of wash it out, that you could kind of track a phone, which would be real bad.
But there is definitely a lot of potential there for sure. I mean we have played around with it with some simple apps, et cetera. But the bulk of it still is kind of fixed sensor that people put up on fixed locations so far.
CRAIG: That makes sense. I'm glad to hear that you're thinking hard about that stuff because I think it sounds like you're pretty far out at the edge, and it's great to hear that the people that are out there are really considering that stuff rather than putting something in place and then later going, huh, well, didn't intend for that to happen. I think very wise on your part to show some caution. Cool.
I thought maybe we could turn towards – this is really interesting stuff, but I thought maybe we could turn towards some of the technical pieces. You both mentioned Clojure as being part of the tools that you use on a regular basis. Obviously that's probably the central technology theme for this show anyway is Clojure.
Here you've built a really non – you've solved or are in the process of solving and have solved some really nontrivial problems using it, so I don't know what specifically to ask you. I'd just love to hear your experience and places where you feel like Clojure has been a big win.
You said you were a huge fan from a data side. Martin, you've written a bunch of things about Clojure that I think are very thought provoking and interesting, so I'd just love to hear each of you give a chance to just weigh in on, yeah, Clojure has been great for this or for this it would have been whatever. That would be lovely to hear.
MARTIN: If I can start, I think it's interesting because it kind of influenced the company both kind of culturally and technically. It's always been kind of a technology driven company, so it's one of those startups where tech guys come together and try to do something cool instead of a sales guy trying to sell something.
The people that founded it kind of found themselves or found each other in the Clojure community circles, so a lot of what's been going on in the Clojure community, in London at least, that's kind of is what birthed the company. It's quite interesting. I think both Yodit and I, and some other guys, have been involved from the beginning, like Malcolm in JUXT, which I know you've spoken to previously was also one of the founders. Going to conferences, talking about it to other Clojure people, hearing what they are doing, exploring the big data side like Yodit has been doing, I think it's been instrumental in not just what we've done technically, but also setting the tone and the culture in the company, which is quite interesting.
CRAIG: I'd love for you to expand on that a little bit. Obviously you think it's been beneficial, but in what sense has that been true?
MARTIN: Yeah, I mean in my mind, one of the draws to Clojure for me was the community in London and a big thanks to Bruce, James, and those guys who are still running it. The Clojure community is–I don't know–everybody. If you've been exposed to a couple of language communities, one thing that strikes you is how different they are. The Clojure community, to me at least, has always been very warm and welcoming, helpful to begin with, people sitting together trying to solve problems together in dojos or hack days or whatever. Just getting people up and running, solving problems, and talking about how to do things better.
One of the things with the Clojure community as well is we are writing a lot of libraries with really clever names. Just keeping on top of that has been very interesting. Of course I think the learning is one thing I think that's unique for the Clojure community. I think we all learn a lot and we're very engaged. I think that's really helped. Those are the couple of things I would highlight.
Then, of course, as the community grows, you find new people to work with and you kind of expand your network of people who can work, you want to work with that way as well. It's been beneficial that way, I'd say, the culture. Then technically, I'll hand it over to Yodit to take over for a bit now.
CRAIG: Okay.
YODIT: Yeah. It's been interesting because obviously when we started, we started maybe, what, ten and a half years ago. The way we view new technology is probably transitioned. We experimented with so many of the early libraries in Clojure. We were kind of probably the first. I think ClojureScript was probably released though. I didn't even know if it was out of beta when we started using it.
There's been times when we've – it's been really, really exciting to be part of the Clojure journey. Clojure is still a very young language and the community is very young. It feels like we've kind of developed alongside the language, and now we're much more thinking about obviously stability and things like that. As we mature as a company, I suppose the kind of transition in how we look at languages and how we assess languages also has changed, and there's lots of things. I think we'll probably stick with Clojure for lots of things, and then we'll also experiment with other things.
I suppose the relationship, it's been an interesting transition building a company around a language, if that makes sense. Also, yeah, in terms of culturally as a company, I think generally we're all – I mean can I call us older, burnt out, experienced people? I don't know how to describe–
[Laughter]
YODIT: There's a lot of "been there, done that" folks where we have, I probably have a love/hate relationship still with Java, but I don't think I'll probably write again. I'm kind of firmly in the FP account firmly for the rest of my career. I don't know, unless something blows my mind over the next, you know, few years. Yeah, that kind of brings me together a collection of individuals that are a bit world weary, have seen things go wrong and are firmly in the FP camp. Would that be fair to say, Martin?
MARTIN: Yeah, I think. I think a lot of the earlier – if you look back, like I've been doing Clojure, like I said, for five years. The first generation or whatever you want to call them, most of them were surviving Java developers who's been spending a lot of time writing backend systems, whatever, in Java with a lot of experience on real world topics and all kind of sharing this dream that there must be a better way. There must be a cleaner way.
Just sharing that vision and the kind of excitement, I think it's taken us far, just the mindset. On a technical level, I think Clojure, it's a good fit for startups because you can definitely explore a lot of things. You can get a lot of things done quickly in both the backend and the front end, which we definitely benefited from.
Then also we could – since we have had Java developers onboard from the beginning, you can still leverage all this Java experience on big pieces of infrastructure. You can bring in, like, everything is there. You can talk to any database. You can set up core clusters. You can do whatever. There is no big wheels to reinvent, which I think that pragmatism of Clojure is one of the keys why it's so popular.
CRAIG: Yeah, that's interesting. Obviously I agree. You kind of sparked something for me, though, which is you emphasized the fact that one of the things you like about Clojure is the fact that people are kind of explorers. They have – not to say everybody is a certain way, but there is certainly a tendency at large, I think, to be interested in new ideas.
And so I'm sitting here thinking, well, you know you are going out into new areas. Internet of Things is just too new. You have to be explorers not only in things like languages, like I might be applying it. It's a new tool, but it's an old problem, perhaps. But you're actually applying a new tool–new-ish tool anyway–to a new problem.
And so I'm wondering what else have you encountered? We all love Clojure, but what else are you excited about right now? You've seen other tools. It doesn't have to be a language, but things that you're like, oh, this. This is going to be awesome, or this is really interesting and maybe could really help us because I think just the nature of your work means that you're going to have to be thinking about stuff. So what should I be excited about that's out there that you're interested in?
MARTIN: Do you want to start, Yodit?
YODIT: I'll let you start. I'm playing pointing-haired boss these days.
MARTIN: Oh, okay.
YODIT: My explorer phase is probably kind of coming to an end, and I end up thinking, oh, my God. Are we going to ship the product? My assessment now is like, is this thing going to let us ship? It's sad, but it's my role.
MARTIN: Yeah. We tend to play those roles a bit, so I'll get very excited. Oh, my God. We have to write this new app in Elm, and Yodit, oh, wait…. Then it's too late.
CRAIG: But I think that dynamic is awesome, right?
MARTIN: Yeah.
CRAIG: I've definitely been involved in efforts where the ooh-shiny, is the only consideration, and you know it doesn't work. You really do need to say, "Well, that's great, but the benefits have to outweigh the costs."
Maybe we could do it like this. Martin, you could tell us what things you think are out that are awesome and, Yodit, you can put on your pointy-haired wig and tell us, "Well, that's cool, but I'm concerned that these things may not be practical or that they may have these costs." We could try it like that if it makes any sense.
MARTIN: Yeah. I guess if you look through the different kind of generations, we have rewritten our backend completely. Three times is it now?
YODIT: Oh, my God. Yeah.
MARTIN: One of the things is you tend to move more and more to this is the classical. Not everybody is doing, moving more to service data stores and more service things, so to cut down your operational problems and stuff like that. We're doing a lot of hard lessons learned on the dev op side and trying to run our own data stores clustered and moving away to more established things like dynamo and stuff like that.
I think what's going on, I mean I think the next reinvent is just a few months in the future. Like any startup, we're kind of terrified if we're going to get killed this and the next year…. But I think what's going on, on the big service providers like Azure and AWS is definitely exciting. Yes, this stuff, and also the stuff they've been doing a long time like Dynamo and the way they keep evolving those things is really impressive. Us adopting that more and more has definitely helped us. Everything that's going on in that space is really exciting for me.
On a more kind of day-to-day level, I'm definitely one of the explorers personally when it comes to languages and libraries, not just shiny things, but also I think it's part of my personality to try. One of the reasons I fell into Clojure was because I was looking around for other things. There must be better ways of doing it.
I was actually coming from F# to Clojure, which might be a strange move. F# about six years ago really kind of rekindled my love for FP. Prior to that I was doing some FP at university, but the problem with FP or the Lisps and schemes and the SICP book and everything, back then it's always been that it's so great in the kind of world garden of the core libraries. But if you want to go out and do something practical and actually redefine from disk something, you need a different kind of language. During my career, it's always been the most disappointing things with all the kind of old school language just like that that actually doing something it was so hard.
I think when I discovered F# and later Clojure, what really opened my eyes was that, oh, my God, you can actually now – here's a language or framework where you can actually get stuff done and still use all these good lessons and write cleaner code. That's what was a real revelation for me, and I think the thing with programming languages as well is it's such a personal thing. I think one of the problems we get as a community is when people learn new things or they get involved in new communities. There's so much kind of emotional investment here.
I think what we have to remember is that it's such a personal preference kind of thing, right? When somebody says that, oh, this library is better than that library, that's one voice. That's based on that person's experiences. It doesn't make it universally true. I think we should all realize that we're all on kind of personal journeys and people grow and find other things interesting, and it doesn't negate the other people's experiences. I think that's quite crucial.
For me personally, one of the lessons learned for us is, like I said, we've been using ClojureScript for a long time. We've been very early on ClojureScript and very early on some of the famous libraries like Om and React. We're starting our third maybe rewrite of the front ends now, and we are exploring a language called Elm, which I believe and some of the people I'm working with here can help us. Maybe it's just us the way we use it, but front end development is very hard. We come to the conclusion, or I have and some of the contracts we work with, all the help we can get from a compiler would help us here. So I'm personally looking into that, and it's going great so far. But I guess my point is that if the listeners here are interested in those, I encourage them to explore it, but it doesn't negate all the good work and all the fruits we have reaped from Clojure and ClojureScript.
I'm personally in a bit of a technology kind of transition phase at the moment, and I think the company as a whole is. Since we're a small startup, I'm kind of dragging Yodit and other poor souls along. It's two things, right? It's the kind of day-to-day cogs and bricks of writing code and working the code base and evolving it and working in the team, and then kind of the big move, the big things on the horizon like all the big hosted services that are out there that we should try to explore as well as we can. It's really general there on a technology … I'd say.
YODIT: Yeah, and also determines, I mean technology choices. I mean if I talk about I still feel like I have a long ways to go to being the kind of developer that I want to be. One day the kind of developer I want to be is to be able to pull out the tools that suit the job. I want to be good enough and, you know, from our line to every tool that's necessary in order for me to kind of solve the problem.
Sometimes we don't talk enough about what's the appropriate tool to solve this particular problem and maybe how we can all just be flexible and just kind of have a bag of tools rather than necessarily kind of sticking to one. That's, I suppose, the kind of master craftsman type attitude that I take. It'll probably be by the end of my career, but at some point I'd like to be able to just be able to just swiftly pull out any chisel or hammer and be able to make something. On a personal level I think the exploring is good and we're all trying to get better, right?
CRAIG: Yeah. I agree with what you both said. It's really interesting. I've lately come to say that there are only two hard problems in software development. Of course there's a joke that starts like that, but the two hard problems, in my opinion, are the speed of light and people. I think what you've both said is there's a lot of people stuff in there.
Yodit, you mentioned being able to focus on–hopefully not misstate what you said–that there are these factors, like can we focus on what problem needs to get solved together and figure out how to go about doing that. I think that's a super hard problem, actually, with team development.
Martin, I was interested when you said – you mentioned a whole bunch of stuff that has to do with operating software, which is an enormous problem and one that I think at least I as a developer have for most of my career spent less attention on than I should - just really interesting stuff. It's cool to get your perspective on that.
MARTIN: Yeah. I've been semi interested in the op side for a long time, and being interested has kind of got me half involved in the operational side, so I've written a fair bit of Chef, Puppet, and everything back in the day and spent a lot of time with Docker containers and setting everybody's environment up.
One of the biggest changes as well we've done recently in OpenSensors, like a year ago, a year and a half ago, we really transitioned from the prototype phase to like a proper production phase. One of our biggest technical kind of … there was really shore up the operation side. I find it interesting, but it exposes. Quite interesting for me, it exposes some new sides to the languages and runtimes that we use, which are a really interesting and important part of the whole process, I'd say. That's another area where Clojure is really strong, at least in the backend where we have all the running and ops tool around the JVM, so we can monitor it. It is understood how we package and launch it.
People complain a lot about stack trace … but one of the reasons they are very robust is that when something blows up in production, you really want the verbose and elaborate stack trace to really figure out what happened. When you start exploring other languages, like I always do, like let's take an example like Haskell with Lazy evaluation and not so much optimized for operational–not yet at least–where if you try to form a kind of informed opinion on the language and the runtime as a whole, I think those sides are really important.
It's not just about the type checker or how clean you can do quick sort. It's actually, okay, once you have this executable, how do you monitor it? How do you kind of run it in production? How do you know what part of it is slow, et cetera?
CRAIG: Mm-hmm.
MARTIN: I think with my experience as well, these are the things that, on my spare time, that I think about when I go on my adventures.
CRAIG: Yeah, it's interesting. You write a piece of software, and you maybe spend–pick a number–three months writing it. Then it lives for maybe five years.
MARTIN: Yeah.
CRAIG: It makes a lot of sense, to some degree, and to more probably than we often do, to emphasize the five years, right? What's that going to be like?
MARTIN: Yeah, exactly.
CRAIG: Yeah. Cool stuff. Well, I don't want to keep you all day, although absolutely fascinating conversation. Maybe this would be a good time to transition to the part of the show where I always like to leave time in the show for the guest, if they have anything that they're like, oh, good, I'm going to get a chance to talk to Craig and his listeners. Maybe I should mention X.
People don't always have something, but they often do, and so I always like to leave space rather than me just setting the agenda here. We'll start with you, Martin. Is there anything that you would like us to talk about today? We have plenty of time still, but let's make sure that we leave a block here to do that.
MARTIN: We have a shameless plug here.
CRAIG: Oh, yeah. Please.
YODIT: Oh, yeah. Please.
CRAIG: Please, please, please.
MARTIN: If you will cut this out, but–
CRAIG: Nope, not at all.
MARTIN: OpenSensors is hiring, so if you're keen. First of all, we are a very remote team, so we have people in Bulgaria, Russia, et cetera, all over Europe, all kinds of time zones at the moment. We need help on the backend and front end. If you're looking for work, please get in touch with us. That's the shameless plug we promised ourselves not to forget.
CRAIG: Ah, yeah. No, that's great, actually. I mean Clojure has gotten a lot bigger in the last–whatever we're at now–seven or eight years, but it's still not huge. I personally think that there is actually a – I know there are people that are working to solve this problem, but I feel like go in and talk to people, and they're like, "I love Clojure. I'd love to work in Clojure, but my company is not doing it." Then I talk to other companies and they're like, "Yeah, we really like Clojure, but we're having a hard time hiring." I'm like these two things cannot simultaneously be true.
MARTIN: Yeah.
CRAIG: I think it's great that you're letting our listeners know that you would love to talk to them. I'm assuming they can contact you at OpenSensors.io to find out more.
MARTIN: Yeah, absolutely.
CRAIG: Excellent. Awesome, so that's definitely worth mentioning. Anything else you wanted to mention, Martin?
MARTIN: Let's bring Yodit back in.
CRAIG: Okay, great. Yodit, anything that you want to lay on us?
YODIT: I don't know. For people that are looking at IoT and thinking about how they can get into it, I think we should actually talk a little bit about the skill sets that people will need. One of the things that is lacking is embedded systems programmers. For those of you that are either getting your kids into programming or kind of revisiting electronics and embedded systems are going to be amazingly massive over the next ten years.
Just like data maybe over the last five to ten years has been, you know, data science data has been the thing to root for, I think in terms of just to kind of complete the circle in the Internet of Things, electronics and firmware development in any way is going to be a key for a lot of industries. You have a lot of kind of very traditional industries that are starting to sensorize everything, so manufacturing to connected cars to engineering. We're just going to see an explosion in the demand for these skill sets. I would say, as a word of advice to anyone that's kind of looking at this area, dust out your old electronics books.
MARTIN: It's becoming a bit of a lost art, at least to us coming from a software perspective. People who are comfortable of bringing up the C compiler on assembly and you're cracking out, fiddling the bits in the device driver, right? I don't know what indication the situation is, but it seems like the focus is a lot on JavaScript, Python, and stuff.
YODIT: Yeah. Does anybody even teach C any more in computer science degrees?
MARTIN: There must be. There must be somewhere. That generation will eventually retire, so there will be a huge gap there for somebody.
CRAIG: Yeah. My education is now two decades behind me, but I feel like that stuff may be more the providence of electrical engineering right now than computer science, despite the fact that there is, as you point out, very good reason. The other thing that occurs to me though is that I think there is reason for hope in the sense that device programming has never been as accessible as it is right now with things like Arduino and Raspberry Pi to a lesser degree in the device sense. Anybody can go out and spend $15 and download some open source software now and make a thing that's not running any operating system. It's just like a microcontroller and working with sensors. I think that's really promising as a source of the skill set that you're talking about.
MARTIN: Yeah.
CRAIG: Cool.
MARTIN: Absolutely.
CRAIG: Well, awesome. That's good stuff. Sorry, Yodit. I didn't mean to cut you off. If there was anything else you wanted to mention, we certainly have time for that.
YODIT: Oh, no. That's me done.
CRAIG: Cool.
YODIT: I'll give the mic back to Martin.
CRAIG: Yes, because Martin, of course, we have another question for you, as we always end the show with it. The question has to do with advice. We always ask our guest to share a little bit of advice with our listeners, whatever stripe of advice they think is worth sharing. What would you like to share with us?
MARTIN: Yeah, so I would come back a little bit to maybe what I said before, but I think people interested in Clojure are, like I said, I think if you look at the people in the communities, they are people interested in learning new things and exploring different parts. They're interested in the craft and how to improve themselves.
One little thing, I don't know why it is, but something that I found slightly discouraging is that people seem to get tribal over technology libraries or whatever it is. My advice is if you have that tendency, try to fight it within yourself.
For instance, one thing that I found very encouraging is the kind of cross-community conferences like Strange Loop. We had one in London called Code Mesh. Those conferences are absolutely amazing. Different communities come together, and I think that's quite rare, actually. I think, in our industry, a lot of people – you're a Scala developer, you go to Scala conferences and you read Scala blogs. That's what you do.
Some people get some kind of emotional investment in this, which I encourage people to fight. Take in new things. Go to those great – you know, join other communities. There's definitely no shame in that. I think you are better for it. If you got into Clojure, you come a long way, but you can never stop. There's always a bigger fish out there.
CRAIG: I think that's excellent advice, and I agree with you. I think you need to look no further than conferences like Strange Loop or Code Mesh. I haven't been to Code Mesh, but I love Strange Loop. One of the reasons I love it is because exactly what you said. And I often go, in fact have gone for the last two years and going again this year, to RacketCon.
MARTIN: Yeah.
CRAIG: To be there, even though that is a language, specific one, but to be there with them and not as someone who identifies as Racket is also really enlightening, so I think that speaks exactly to what you're talking about.
MARTIN: I think the Racket community, I mean obviously a lot smaller than Clojure, but it seems to be a fantastic community as well.
CRAIG: Yeah.
MARTIN: I think the other thing, if you go to other meet-ups and spend some time in other communities, you appreciate how different they are. I think, for Racket, they're more rooted in academia, which I think it's nice. In Clojure, we're not super academic, if you know what I mean. We are. We read a lot of papers and we're keen in it, but if contrast it to Racket, I think it's quite different. I think you will surprise yourself how much you would enjoy it, like you said, to mingle in those communities.
I think a little bonus advice from me here is if you go to these kind of conferences, or any conference really, for me the best track is the corridor track, right?
CRAIG: Mm-hmm.
MARTIN: That's what it's all about. Nowadays all the presentations are online. You can sit and watch them in 1.5x or whatever too if you want to save some time at home. But the corridor track is where it's at. Some of my best conference experiences definitely hanging out in the corridor in Code Mesh and just having chats with amazing people from the creator of Elixir or some author of a book I forgot I read and all these serendipitous little events is something that you can live on for the rest of the year until Strange Loop is on again, right?
CRAIG: Absolutely. Yep. I can neither disagree nor think of a better place to end than with that excellent advice. We will close it down there, but not before I thank both of you for coming on, taking the time to come on today. I know that the life of people that work at startups is a busy one, and so I really appreciate you both taking the time just to stop by and chat today. Absolutely fascinating stuff, interesting to hear about your work at OpenSensors.io, and about your perspective on all the things we talked about. Very, very cool stuff. Thanks a ton for coming on the show, Martin and Yodit.
MARTIN: Thank you.
YODIT: Thank you so much for having us.
CRAIG: It was my pleasure.
MARTIN: Yep.
CRAIG: Excellent. All right, then. We will go ahead and close it down there. This has been The Cognicast.
[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]
CRAIG: You have been listening to The Cognicast. The Cognicast is a production of Cognitect, Inc. Cognitect are the makers of Datomic, and we provide consulting services around it, Clojure, and a host of other technologies to businesses ranging from the smallest startups to the Fortune 50. You can find us on the Web at cognitect.com and on Twitter, @Cognitect. You can subscribe to The Cognicast, listen to past episodes, and view cover art, show notes, and episode transcripts at our home on the Web, cognitect.com/podcast. You can contact the show by tweeting @Cognicast or by emailing us at podcast@cognitect.com.
Our guest today was Yodit Stanton and Martin Trojer. Yodit is on Twitter, @YoditStanton, and Martin is on Twitter, @MartinTrojer. Episode cover art is by Michael Parenteau, audio production by Russ Olsen and Daemian Mack. The Cognicast is produced by Kim Foster. Our theme music is Thumbs Up (for Rock N' Roll) by Kill the Noise with Feed Me. I'm your host, Craig Andera. Thanks for listening.