# TRANSCRIPT

**CRAIG**:     Hello, and welcome to Episode 109 of The Cognicast, a podcast by Cognitect, Inc. about software and the people who create it.  I'm your host, Craig Andera.  

Well, let's see.  What do we have on the old announcement list today?  Well, for starters, and appropriate to our guest, as you'll see, I want to make sure to remind you that XT16 is coming up.  This is put on by some of our good friends over in England, specifically some people at JUXT.  And so this conference, pretty cool conference.  You should check it out at their website.  That's juxt.pro.  I'm sure you'll find all the information you need there.

This is a little conference, little meaning small attendance.  The tickets are limited, so you'll definitely want to get in on this before it's too late.  It's going to be held out in the countryside in Bedfordshire.  It sounds lovely.  I've never been, but it certainly sounds like a really cool venue.  Of course, with the people that are involved, I expect that this will be a topnotch conference.  Go ahead and check that out.

While we're talking about things over in England, there is a ClojureBridge happening in London.  I should mention that the XT16, that's October 6th in 2016.  Backing up from there a little bit, the ClojureBridge in London is going to be September 30th through October 1st.  Of course you can find out about that and all ClojureBridges at the website ClojureBridge.org.  

Of course, speaking of ClojureBridge, there's also one in Boston coming up.  I went to school in Boston.  Love the area.  If you're in the area, you should consider checking out the ClojureBridge Boston that's happening October 14th and 15th.  All of this is in 2016, of course.  Again, that's ClojureBridge.org for more information about that.

Finally, I'll mention that the Clojure/conj opportunity grant application deadline is September 16th.  The CFP also closes on September 16th.  Clojure/conj is coming up in Austin, Texas.  That's going to be at the beginning of December.  A couple of important deadlines there around the opportunity grant applications and, of course, the CFP.  If you are considering participating in either of those, you should make sure that you do so before that deadline of September 16th.  

That'll do it for announcements.  We'll go ahead and go on to Episode 109 of The Cognicast.  

[Music: "Thumbs Up (for Rock N' Roll)" by Kill the Noise and Feed Me]

**CRAIG**:     Cool.  All right, I think we're ready to go.  Are you ready to go?

**FRANKIE**:     I'm ready to go.

**CRAIG**:     Perfect.  All right, well, welcome, everybody.  Today is Tuesday, August 16th in 2016, and this is The Cognicast.  Our guest today, we are very pleased to welcome to the show, is Francesco Sardo, also known to many on the Internet as Frankie Sardo.  Welcome to the show, Frankie.

**FRANKIE**:     Thanks, guys.  I'm glad to be here.

**CRAIG**:     We are thrilled to have you, and we'll get into why in a minute, why we chose to have you on.  That was certainly intentional and a choice we're excited about.  

Before we do that, we do ask you the question we ask every guest at the beginning of the show, a question about art.  Specifically the question is, what experience of art, whatever that means to you, would you like to share with us?  This could be anything from a book you read to a painting you saw to, hey, I saw a cloud that looked like a unicorn yesterday and it made me think of my childhood.  Whatever it means to you, we hope that you have some experience, some artistic experience you'd like to share with us.  

**FRANKIE**:     Well, sure.  What I'd like to share is something that happened to me a couple of months ago while I was training.  I do train in martial arts, specifically in Tai Chi, which is not the answer that someone would expect when you say training in martial arts.  They immediately think, you know, Kung Fu, spinning kicks and punches with high pitch noise, Bruce Lee style.  It can be a quite demanding martial art, especially to do all these slow movements in a flowing and harmonious way.  You need a certain degree of flexibility and strength.  

Every Saturday we train with other students here in London with the head teacher of our school for a full day with quite intense training, boot camp style.  In that particular day, it was more intense than usual.  Our head teacher was pushing us quite a lot, and it was surprisingly hot for London standards, so above 35 degrees (Celsius).  We're all sweaty and all sore from the training.  

The morning ends, and we're having a little break having some tea and some nibbles before the afternoon session.  So we slowly walked back in, into the gym, one by one, feeling a little bit what was going to happen in the afternoon session.  But what we saw was a little bit surprising.  Our teacher, instead of being on the podium and looking at us, and he can be quite intimidating.  He's a big man.  He's done a lot of martial arts, so he can be quite intimidating.  He was just sitting in a corner reading a newspaper and music, something like Frank Sinatra or some kind of music like that, very soothing, very calming was playing in the gym.  

All the students, one by one, started to walk into the gym.  They do their stretches, their warm-ups to be ready for the afternoon.  I have to say I'm really lucky to be training with them because they are all way above my level.  They move in a fantastic way, each one of them.  They're very skilled martial artists.  The way they move, it can be mesmerizing.  You can just sit down and look at them for hours. 

You see all these students, one by one, coming in and starting doing some stretches, and I was at the back of the room doing some stretches as well.  All the sight of these students reawakening their bodies after all that training, the teacher at the end of the room, the music, and the warmth in the room, it was just a beautiful sight, a beautiful kinesthetic experience.  I realized that that was what we needed, so our teacher sort of like designed that experience for us because that's what we needed after an intense training.  Surely it was beautiful, and it was even more beautiful because it didn't last long and then, after a couple of minutes, we were back training and sweating again.  But I really savored that moment during that day.  

**CRAIG**:     I love that story.  That's so interesting.  I think, thinking back, I believe you're the first person to share a martial art, but that's fantastic.  It certainly fits with my definition of art, which is an experience or object that is intended to evoke some emotion.  I don't propose that as a universal description, but it is one that I use.  Clearly that experience had that effect on you, and your description as well was also very evocative for me, so that's a really cool story.  Thanks for sharing that. 

**FRANKIE**:     Yep.  

**CRAIG**:     All right, well that's awesome, and I'm sure, actually, I have a bunch of questions for you about Tai Chi, but maybe we will turn to technical things for a while first.  Perhaps we'll come back to the question of Tai Chi.

**FRANKIE**:     Sure.

**CRAIG**:     You describe yourself as a full stack developer, which I think is a really interesting thing to be right now and to be in the space that you and I spend most of our time in technically.  At least I assume you spend most of your time there.  I certainly do.  Namely the Clojure stack, right?  

We have this set of technologies, and I think they really facilitate spanning frontend and backend in a way that the technologies that I personally have used historically have not.  When I started out, I was a C++ developer and browser apps didn't really exist.  But if they did, you certainly weren't writing them in C++.  Later, the same was true for C#.  

Anyway, I just wondered whether you could speak a little bit to that whole concept of full stack and your experience of full stack because I sense, by looking at your various places around the Internet, that you have some thoughts there.  I wonder if you would share with us those.

**FRANKIE**:     Yeah, sure.  I think not many people like to define themselves as full stack, but I believe full stack sort of means I can do damages all across the stack.  That's how I like to think my contribution could be all across from the browser to the server to database migration to setting up microservices.  In an ideal day, especially where I was working before, if you could follow a story, like a business case, a ticket in JIRA from the beginning to the end, so you have the usual case of, oh, let's add the button in the user interface.  When you click it, it does something.  And then the button needs to change the server for the API call.  That needs a new parameter in the database.  Then needs early deployment.  Then needs some sort of other configuration.  

In some type of teams you would only care about the button and the behavior around the button.  Then pass the ball to another team and let them take care of it.  When we were working before, it was an all Clojure team, and we did quite an impressive amount of work with a very small team for quite a big project.  It was for probably the first time where we could see a story growing and completed from the beginning to the end, and so we had full knowledge of all the edge cases, all the implications, and where I think then a clear vision of where was most effective the change.  

If it starts as a user interface change, then probably the user interface person that picks it up tries to make it as good as possible for his domain.  Then if it's more complicated in other domains, it doesn't really matter.  Or if it mattered, then he has to go all the cycle back to him to modify something and to readjust something in the code that he wrote.  But if you own the story across the entire stack, then you'd be much more effective in making the exact change, you know, that that's the most profound impact and delivers, let's say, the best value for the business.  That's what I think we managed to accomplish in a full Clojure team.

We were doing Clojure and JavaScript at the time.  Then we started to migrate towards ClojureScript.  But it was certainly the most challenging and most interesting experience in my career time, and so everywhere I went after that I tried to mix the roles that I was taking within the company and tried to do a little bit of everything to get a knowledge of the business 360 degrees, let's say.

**CRAIG**:     Mm-hmm.  Yeah, I mean I know I've certainly had the experience where, when I'm designing a system, I really like to look at it from all angles.  I think there's one school of thought that says you build it up.  You start with a data model.  Then from that you build a set of services that expose it.  Then from that you build a UI.  But I think that the UI actually informs a lot of times the data model and vice versa.

**FRANKIE**:     Mm-hmm.  Exactly.

**CRAIG**:     And so I like that idea that when you're working on something, the more visibility you have across the system and, in your example, that takes the form of a story.  I think it's kind of a complementary or one expression of that design esthetic is there's a story that comes in.

**FRANKIE**:     Mm-hmm.

**CRAIG**:     I like that idea that the more visibility you have across a system, the better you're able to make decisions at all levels.  I wonder, though.  As you've tried to take that approach, have you encountered any challenges?

I myself have been spending more and more time lately with ClojureScript and in the browser.  I don't consider myself an expert there.  I would not be happy being put in a position where someone said, "Oh, we've got this guy.  He's a total expert on building browser based systems."  No, that's not really me.  My expertise is elsewhere, but I still can play in that area. 

I think it makes me more literate, but I wonder whether, as you've attempted to broaden your horizons, attempted to take that wide view, whether you've discovered any challenges or trade-offs in it.  I think one of the other primary rules of design is everything is a tradeoff, right?  You're always giving something to get something.

**FRANKIE**:     Oh, yeah.

**CRAIG**:     What do you think those are in that arena?

**FRANKIE**:     No, what you said I think it's really true.  If you work all across the stack then you're giving away depth for breadth of knowledge.  You can't be as effective in doing some UI changes as someone who is only very specific in doing beautiful UIs and beautiful animations.  I think, in the best of worlds, in some time it did happen.  You will prepare, and you will have someone in the team with, let's say, some bias towards user interface or database, let's say management, you know, someone really experienced with Datomic, someone really experienced with ClojureScript, and someone really experienced in microservices.
    
If someone has, let's say, bias or more affinity towards a certain part of the application then it will also have more interchange happenings to share their knowledge across the team, and it will be a pleasure to pair with that specific person in that area.  And it will give you the best tips on how to get started and how to get the correct design of a single page ClojureScript application, for example.  But that's the ideal world.  Sometimes it does not happen.

I think it's still interesting to expose yourself to these even for a little while.  The tendency is to do only the things that you know you can do all the time because that's how you spend your day.  If you're in the microservices space, then you just create a new microservice, and you have your Leiningen template that will get you up to speed in five minutes.  You sort of like enjoy it and you're very fast at doing them, so there is this tendency of fast system that consume a lot of work to be given even more work.  If you are a very fast ClojureScript developer, then you will get more ClojureScript work, and you'd never have time to dip your toes in what's behind the server, the databases, and whatever, Amazon architecture and messaging, parsing, your business is doing.  

It's nice sometimes to step back a little bit from what you do usually and take a look around.  Probably because of your past experience in certain areas, you will see things in a way that people that are deep in that space don't see.  Certainly the fact that it's the same language all across the stack.  If you're using ClojureScript, Clojure, and Datomic, it really helps you maybe not being productive right away, but at least understanding what's going on and reading the code and understanding how the data flows through the system.  That's already a good start.  

I will take slowing down the development of the system for spreading the knowledge of the system among the team a little bit more as a compromise much more often because it's something that isn't done enough these days, I think.  That's surely something they can improve in the current philosophy of many companies.  

**CRAIG**:     Yeah.  I totally agree with that.  That's actually an interesting variation on something that I honestly can't remember whether I've shared on the show before.  We've recorded something like 110 episodes now, so people will excuse me a little bit if I can't remember all of them.  

There's a story I like to tell or, rather, a question that goes at the end of a story.  It's a theoretical situation.  Frankie, imagine that you're the manager of a team of, say, ten developers.  The number is not important, but you come into the office on Monday morning and there's a guy there.  Slicked back hair in a ponytail, sunglasses, a black suit.  He's got a cane with a silver top, and he looks kind of sinister.  

He says, "Hey, how are you doing?  My name is Lucifer.  I'm the devil, and I have taken away all of your developers and all of your source code."  He says, "Now don't worry.  Nobody has been hurt.  In fact, your developers are all on a tropical island somewhere enjoying fruity drinks with umbrellas in them.  Nothing bad will ever happen to them.

**"The thing that I've come to do is to give you a choice, you, the manager of this team.  The choice is this**:  I will either give you back all of your developers or all of your source code.  Whichever one you choose, you'll be given that, but the other one you'll never see again."

**FRANKIE**:     Mm-hmm.

**CRAIG**:     You're either going to lose all of your developers or all of your source code.  The question that I've been enjoying asking people is: What do you do?  Which one would you personally pick?  I'll put the question to you, Frankie.  Which one would you pick to keep?

**FRANKIE**:     That sounds easy.  The developers for sure.

**CRAIG**:     Right.

**FRANKIE**:     Because at that point it depends how old is the project.

**CRAIG**:     Right.

**FRANKIE**:     Because at that point if it's old enough then most people would like to rewrite the code base anyway.  

**CRAIG**:     Right.  Right.

**FRANKIE**:     It would be a good occasion to rewrite the entire code base.

**CRAIG**:     Yeah, well, it's a fascinating observation, and I totally agree with you.  Actually, having thought about this a bunch, I think there are one or two situations where you might actually choose to keep the code.

**FRANKIE**:     Mm-hmm.

**CRAIG**:     For instance if you're deriving a huge amount of revenue from a system that's changing very little, then it may actually make business sense to hold onto the code.  You would have time to hire a new team and to build them up before the technical debt or the bug fixes or whatever became critically bad.  But, you know, for a lot of the projects that I've worked on, the vast majority in fact, it would absolutely be the case that I would choose the same as you.  I find that observation really interesting, and it speaks to your comment because it implies to me that the value of the system is not in the code.  

If you're given a choice between the two and you would pick the developers, well clearly the developers are more valuable than the code.  Otherwise you wouldn't pick them.  And so your observation about building value in the team by cross-pollinating between the various disciplines just fits right in with that.  It's like, well, if that's valuable, then spreading it out more among the developers is putting more of that  value into more of the team, and that's a useful team.

I guess that's a very, very long setup for the question, which is, have you seen any mechanisms or practices or anything other than simply making an effort to do so that has been helpful in setting up to encourage that diffusion of knowledge or that cross-disciplinary practice?  What have you seen that's worked for making that happen?

**FRANKIE**:     I'm not a big fan of things imposed from above.  Every time that there is the mandate, you know, test coverage has to be 80% before committing code or each team has to deliver a tech talk  every week to the other team, I haven't seen that working very well because, you know, people don't like to have something imposed on them, especially technical people.  I won't back this up with data, but I've seen technical people somewhat like the worst when someone tells them what they have to do.  They like to discover their own answers.  

I don't know.  I see it working when it comes from within the people, like when you choose people with a natural curiosity to explore.  The best thing that you can do, I think, is to give them time to do that.  Rather than keeping up the pressure in delivering more and more features, business values, story points, or whatever, and the metric you want to track, is when someone says, "Oh, I'd like to spend today to pair with someone on doing this feature on the backend," then you should give them a thumbs up because that could be very valuable.  If not then now, then you will certainly pay off in the future.  
    
I think what you said is it's really in time and in the spirit of what Michael Nygard -- did I pronounce that well?

**CRAIG**:     Yeah, Mike Nygard.  Yep.  

**FRANKIE**:     Michael Nygard was saying about treating the code rather than an asset as a liability.

**CRAIG**:     Right.

**FRANKIE**:     Your real asset is the people that you surround yourself with and their knowledge of the business domain.  If your knowledge is only limited to what the UI should look like, then you're not really valuable.  If your knowledge is about what the purchase voucher feature should work, in general, for the company, then you are really valuable because you'd be able to implement it yourself.  Not maybe at the same quality level, but you know how it works and how it's supposed to work.  You'll be able to re-spec it down and you will be able to explain it to a new member of the team.

I've seen many times people joining the team and being coached for a couple of weeks and only being explained the segment of the domain that the person that they're working with understands.  It's hard to find people that know how things are supposed to work, in general, regardless of the implementation details, and people that can explain that in words really well are even more rare.  If we can train people to be more like this, I think teams in general will benefit from that.

**CRAIG**:     Hmm.  Yeah, that's really interesting.  As you were talking, I was thinking about things like -- and many of these ideas may exist or may be really terrible ideas, but I was thinking about things like you mentioned how we, as an industry, tend to resist imposition of practices or metrics from above.  I think that's true.  But I think people still do respond to incentives.  Maybe not explicit ones, but if a system is set up to reward how many pull requests you create, it'd be a terrible system.  But you will tend to make more pull requests.  

I was wondering whether a system could be set up that would somehow inherently incent that behavior of diffusing knowledge.  Maybe this isn't a very good idea or a very good way to do it, but if you had a metric that was, you know, look at all of the cards in your system and measure the number of people that would be required or the percentage of your team that could implement the whole thing and track that number.  It would be an interesting number whether it would lead to good results or have some unforeseen negative effect.  I don't know.  But if your average number was 10%, like of all the cards in your system, most of them can only be worked on by one out of every ten people on your team versus 90.  Would that be an interesting metric, and would it incent the type of behavior that you're talking about?  It's an interesting question.

**FRANKIE**:     Yeah, I think so.  It's a very interesting topic.  It would be nice to think about this a little bit more because, yeah, whenever there is a gain, then people tend to optimize their behavior towards winning the gain.  If the gain is giving rewards to opening pull requests, then there will certainly be, you know, instant behavior to optimize their day-to-day work to do more pull requests.  So it also needs to be a reliable system that it's not so easy to pervert in such a way. 

**CRAIG**:     Mm-hmm.

**FRANKIE**:     But, yeah, definitely.  Even tracking for each story how many people you require to have completed.  Also, something interesting is what if these key person takes a couple of weeks' holiday.  Then are we able to complete the story?  How many from this pool of people we need in the office or we need available in order to not block the story?  Who are the blockers, the holder of the knowledge?  Certainly if two people are holding down an entire stack, then they will paralyze much of the organization if they take holidays together.  

It's something that is happening in my current gig at the moment because it's much more of a vertical layering of teams, so there's ops, there's microservices, there's server API, there is third party integration, and then there's UI, so all the teams are stacked one on top of the other.  We've already seen the type of behavior that blocks you.  Apart from the cost of being blocked is--I don't know--psychologically it doesn't feel good to depend on something that is out of your control.  I'd much rather prefer to do something somewhere that I don't fully understand, but at least I will make a mistake and I will pay for it.  But at least I've done something rather than wait for someone else to do it for me.

At the end of the day, I will have learned something new.  Maybe if someone is available, I'll ask for help and hopefully we will pair on that particular feature.  Otherwise if no one is available, then you should have the key to at least try and do something.  Obviously try not to break everything, but if you don't trust the developers that work with you and for you, then you'll be in trouble anyway.  

**CRAIG**:     Yes.  Very true.  Yeah.  Yeah, it's so interesting.  I mean I'm far from an expert on these things, but I find your perspective fascinating, and I think I  need to think more about that for the projects that I'm on, how I can better acquire the expertise and system knowledge that other people have, as well as to do a better job of spreading what system knowledge and expertise I have.  
    
I know that you work with our friends over at JUXT quite bit as a consultant and, in general, your work is in the consulting realm, right?

**FRANKIE**:     Exactly.  Yes.

**CRAIG**:     Yeah.

**FRANKIE**:     Very happily so.

**CRAIG**:     Yeah, that's cool.  We like those guys a lot.  That's JUXT as a company, and the individuals there are friends of ours.  You've done the consulting thing, and that's one of the interesting things about consulting, I think, is that it really does force you to confront knowledge transfer in a way that when I was an employee wasn't quite as in my face, right?  

**FRANKIE**:     Mm-hmm.

**CRAIG**:     The thing about consulting engagements is, although some of them do go on for a very long time, there's this much more explicit understanding that they will end.

**FRANKIE**:     Yeah, yeah.

**CRAIG**:     You hire consultants.  They come in.  And then they go away eventually.  Hopefully after a long and fruitful or maybe a short and fruitful effort.  It depends on the engagement, but you do have to think, like, what am I going to leave behind me?  That whole devil's question really comes into it.  

I think, as consultants, we're always challenged to think about how are we getting the knowledge out of our heads so that we don't take it with us when we leave.  Obviously documentation is a part of that.  I think the types  of things you're talking about where we work together, where we spend time together, as equally if not more important.  Would you agree?

**FRANKIE**:     Yeah, and especially onboarding new people.  Sometimes what we do with JUXT is to bootstrap new projects while the company hires more permanent employees.  That effort in bringing up the system from scratch and then suddenly you have a big, complicated system, and you have to hand it over to someone else.  Meanwhile having many people onboarded through the weeks, and obviously you try to write a few lines of the implementation now and then, but you never implement things enough and because you're moving at such a high speed, then the implementation gets out of sync and also deployments. 

Yeah, I personally didn't find anything more effective than trying to work closely with as many people as possible and talking a lot, pairing a lot, and even just encouraging everyone to try their hands on an area, a new area from time-to-time.  If they get stuck, of course, raise your hand.  We will come and help you.  But that idea that there's no sacred code in the code base.  Everything is up for someone to opening up, modifying, and submit a pull request.  No one should be in touch about a particular feature or a particular area.  No one owns anything anywhere.  You should be able to open up as much access as possible, you know, for security reasons, but in general wide access is really preferable because otherwise you will feel always a bit frustrated when you have to ask other people to do things for you rather than just -- that's what I feel, at least.  I like to open up the code base.  Change a few things.  Run the test.  See that it broke something.  What did it break?  Try to understand how it worked.  

I think, especially with the consultancy, it's a great occasion to try your skills in many different ways because each project is so much different from the other, even though they might all be Clojure projects.  There's such interesting requirements and such a new way of solving problems.  Also because Clojure and the ecosystem around Clojure moves so fast, so in a year time you would like to try something that came up just recently.  That shapes again the way you approach certain problems.  

A couple of years ago we will never have used--I don't know--Om or Reagent, and now it seems like the obvious choice.  It's a completely different way of approaching a problem.  Suddenly something that might have seen very complicated becomes trivial.  Obviously you have the challenges of understanding a new toolset, a new way of doing things, and you're always learning, which is, I think, the best reward in itself.

**CRAIG**:     Yeah, it's interesting.  This drives me in a couple ways to something else I wanted to talk to you about.  We were talking about the value of spreading knowledge, and you mentioned new tooling, new ideas, or at least ideas that are new to you, even if the ideas themselves are old.  

**FRANKIE**:     Mm-hmm.

**CRAIG**:     One of the things I came across when I was looking at your profile on the Internet was that you've been working a bit with spec lately.  I wondered, since it's a new thing that we're all new to, spec specifically.  Obviously it's similar.  The idea of contracts have been around for a long time, but spec specifically looks like something you've had a chance to mess around with a little bit or maybe even use in anger.  

I have been experimenting with it as well.  But we're always interested to hear.  It's not even out yet really, right?  It's part of Clojure 1.9 alpha whatever.

**FRANKIE**:     Yeah.

**CRAIG**:     I was relating this to somebody else too.  There was an amusing tweet.  I'll try to find the citation for it some other time, but the day after spec was announced somebody posted a tweet that said, "Looking for a Clojure engineer.  Must have three years experience with spec."

**FRANKIE**:     Yeah.

**CRAIG**:     You saw that one?

**FRANKIE**:     Yes.

**CRAIG**:     Anyway, I guess what I'm asking you is a couple things.  First of all, broadly, what's your experience been with clojure.spec?  Maybe you're just getting started with it.  That's fine.  

Secondly, to the extent that you have used it, do you think it's a valid tool or to what extent is it a valid tool for helping to create an understanding of the code base?  Obviously it's limited in some respects, but I'll let you speak to that yourself.  What would you say to those two dimensions of clojure.spec?

**FRANKIE**:     I would say that I wished I used it a little bit more, to answer this question more, probably.  Yeah, I just used it a little bit, of course, because everyone was curious when it came out.  I used, obviously, Schema a lot, and I used it especially for Swagger integration, which I think is another great tool.  That's also, you know, it was really useful for creating Web servers in general and having a defined schema for inbound and outbound responses.  Before that, anything before that, you look at it and it's like looking at people doing the high jump before Fosbury.  It's like, wow, it's a massive step forward.  

Yeah, obviously when clojure.spec came out, I wanted to try it out.  One little exercise that I implemented was trying to pass the pedestal route in syntax using clojure.spec.  I really like the fact that clojure.spec has these powerful vector specification and coercion, so you can match certain things, you know, a vector in a sequence, and it will give you back a map trying to bind the things that it found in the vector to key values in the return map, which is exactly what pedestal routing was doing while passing the routes from the DLS to one of the precompiled route formats.  And it works brilliantly for that.

    One of the problems, especially when you have a vector as a sequence, as an input for your function, is specifying how these vectors should look like, especially if it's a DLS.  You can write some examples.  You can write some checks and preconditions.  But with clojure.spec, I really found that the way it describes what are the accepted input is really useful and really easy to understand.  That worked great.  Once you basically write down what it should look like, then executing--spec calls it--Conform, so conforming the input to the specification will give you back already the parsed tree, so the parsed nested vector if you have, for example, a recursive specification.  Without you writing any line of code, that's just conforming an input to the spec.  It would already do that for you, which is another thing that I found that it's amazing.  

Obviously having test or check generation for that input and making sure that if you have to write any code that changes that input to something else then you will get all these test generations for free, which is another fantastic thing.  But so far I think my only complaint for the little that I looked at clojure.spec, so I might be completely, you know, wrong.  You know, that's the problem that I think every tool that I tried had that is the understandability of error messages.  

I think it's solvable in some ways because clojure.spec gives you data as a representation of an error with a path to the point in the spec where it found the error.  So in theory, it should be possible for you as a consumer for the library to write something that un-mystify that error that you received from clojure.spec.  Yeah, I still have to try my hands on that and see how easy it is.  I think it's a great addition, and I'm looking forward to using more of it.  

I think in my current project someone already started to use it, especially for Datomic schemas and validation, which I think it's an area that many people asked help for and clojure.spec surely helps in that area.  But I wouldn't know much because I haven't tried my hands on it.

**CRAIG**:     Fair enough.  That's still good insight.  You mentioned error messages, and it flashed through my head as you were saying that.  I think that one actually might be a function of the fact that we don't, or at least I'm not aware of, have good visualization techniques in Clojure. 

I personally would really like to have, more than almost anything as a feature, the ability to look at a piece of Clojure data in a visual way.  Here's a vector with 10,000 things in it.  Show me items 900 through 1,000.  The third thing in that is a map of maps.  A vector is with strings as keys and dates as values.  I'd like to be able to visualize that and drill through it. 

**FRANKIE**:     Mm-hmm.

**CRAIG**:     That would be great.  Then once you have, as we already do with clojure.spec, errors that talk about where that data varies from what we think it should look like and where the error is itself data.  Then I think that would combine really powerfully with the visualization tool to say, well, this is what you got, and the pieces that I'm not expecting are red or whatever.  I think that would be great.

**FRANKIE**:     Yeah.  I think there's something like that in the shape of CLJ Inspect or something like that in Emacs that lets you drill down to a data structure sort of like walking through the path of an arbitrary data structure and then visualize it in quite a nice way.  I don't know if you've ever seen it.

**CRAIG**:     No.  Is it part of Cider or is it a standalone thing, or what?

**FRANKIE**:     I think so.  I've been using Cursive recently, but as far as I remember there was this.  I think it's in Cider Inspect or Clojure Inspect.

**CRAIG**:     I know there's a Cider inspector.  There's an old, old, old Clojure inspector that was from early on that hasn't quite risen to the level of what I'd like to see.  Maybe I'm just -- anyway, those are all very interesting things, I think, that I will have to check out.

**FRANKIE**:     Yeah.

**CRAIG**:     I want to move on, though, because one of the things that I'm interested in talking to you about is XT16.  

**FRANKIE**:     Oh, yeah.  Sure.

**CRAIG**:     That's coming up, and my understanding is you're speaking.  In fact, that's how we came to have you on the show is we said, oh, XT16 is coming up.  It looks like a really cool conference.

**FRANKIE**:     It is.

**CRAIG**:     Yeah, right.  It's put on by our friends at JUXT, and we actually went to the organizers and said, "Well, do you think there's anybody that's speaking that would be good to have on the show?"  
They're like, "Well, probably everybody, but we think Frankie would be awesome.  Why don't you talk to him?" 

Anyway, you're speaking there.  I'm not incorrect in assuming that.  In fact, I know I saw your name on the list.  What's your talk going to be about?

**FRANKIE**:     I'm going to be presenting a small talk about the interactive app development, so XT16 is a quite a broad conference, just new ideas in software development.  It's organized by JUXT in a way that tries not to be specific about any particular language, topic, or part of the framework or anything like that.  It's just more new trends, new technologies that we think, they think, it's good to share with a broad audience.  People from other parts of the industry can look at them and maybe be inspired by what they see.  

Because I started as a mobile app developer for a long time, when I first started using ClojureScript with tooling that now we feel like it's part of our day-to-day job.  We just use REPL.  We use Figwheel with instant code reload.  We have an amazing tool like devcards that give us a view of our UI, you know, many particular status all at once.  

If I think about myself back in the days when I was doing mobile development and see this way of developing UIs, my mind would just be blown away.  I think it's somewhat a responsibility to share  more of these things to other people working in closely related fields, for example mobile app development, and showing that there is this possible way of developing code in your day-by-day activity.  

One of the major challenges when you develop a native mobile app is the usual compile time of your app, packaging your app, sending it to a device, clearing whatever local state or app state you have somewhere have to browse through, you know, the voucher confirmation page to see that it looks nice.  Oh, you discover there is a bug, and you go back to your ID and do the process all over again.  We don't do that anymore.

We have found that there are alternative ways of developing that do not mean that these other ways are wrong, but it's  just another way of exploring the code that you develop that help you in a very interactive and very fast feedback with the interface, with the update you're writing.  The talk is not aimed to show much ClojureScript code or not convince anyone to use ClojureScript, but just to see that there are these things that someone else is using and hopefully you may want to try ClojureScript on a mobile app development platform like React native or Cordova, or implement something for your existing stack that enables you to develop in this very fun, very interactive, and very efficient way.  

**CRAIG**:     Yeah, I think it's funny.  I've been a Clojure programmer now for quite a few years.  I was in a relatively early part of the adoption curve, so I take a lot of that stuff for granted.

**FRANKIE**:     Yeah.

**CRAIG**:     I mean until I'm confronted with it.  I'm like, oh, I've got a write a C# app.  Oh, right, I don't have any of that.

Where are we at with that stuff in the native?  You talked a bit about the fact that these are great ideas and we like to bring them to make them available at least to all the other parts of the world, the programming world that don't have them.  But if I was writing a mobile app, let's say an Android app or an iOS app--I don't follow that space at all--to what extent are those ideas available now maybe if I'm doing ClojureScript or maybe if I'm not?  What's the state of the world there?

**FRANKIE**:     The state of the world is not, you know, like the talk will aim to show more of a possible work, but everything will work seamlessly, you know smoothly and seamlessly, and the tools won't break.  You'll have this amazing experience of writing ClojureScript for your native mobile app and you won't need to understand how native app development works.  

The talk won't cover how exactly we are integrating ClojureScript for our native mobile app, but as far as my understanding goes because we implemented for our previous client a mobile app, and we looked into React native, for example, as an option to reuse much of our ClojureScript code base and UI logic for a native app.  We found at that moment in time, it was one year ago, that it wasn't ready yet.  There were just too many -- it was just bleeding, very bleeding edge.  It was just too risky for us to embrace that.  

 What we used instead was Cordova, which obviously it does not strictly qualify as native app development because all it does is just brings up, let's say, a browser view in your device and runs JavaScript on that browser.  What you see, if you're a non-technical user, you see a UI.  You see something that hopefully is as native feeling as possible, but it's just a Web page.  But for our requirements at that time, that was more than enough and it was something that you could install from the app store.  If you have a particular UI branding then you might not even care about native components.

On the plus side, you have all the code reused that you will have for the normal website that you would develop with ClojureScript and all the tooling that I've been mentioning, so you can REPL into your mobile device and change some state in replication and see it re-rendering instantly and develop interactively with the application that you absolutely don't have for native app developments.  For our constraint back in that time, that worked wonder.  Hopefully in the next future, I really hope that something like React native takes off and that we can use ClojureScript to build native UIs for mobile development while keeping all the tooling stuff we're used to and being as productive as we used to are on the Web development and browser development.

**CRAIG**:     Yeah, absolutely.  Yeah, that'd be very cool.  Awesome.  Well that sounds like a really thought provoking talk.  Do you know?  Are the videos going to be available?

**FRANKIE**:     I think so.  The talk, what I've tried to do, hopefully if live coding, goes well, otherwise I'll have to resort with some  backup videos, but I will try to develop an app simultaneously for the browser, iOS, and Android, so three screens together.  That's something that you can do if you use Cordova at the moment, and that's something that I think if you're serious about writing apps.  

I envision a future where you have six, seven screens.  You'll have an iPad, an iPhone, and Android tablet, and Android browser, Android TV, and a Web browser for a full Thunderbolt monitor and a small Web browser.  They will display the same page.  You do a change, and you see all these windows refreshing and rendering your UI for all possible formats for all possible devices.  Why not?  

We can, and it seems backward to just develop a small device and doing all your implementation of your UI there and then, after a couple of days, testing it on other devices, seeing that there are some problems, going back in the code, but you forgot what you were doing and why.  If we have the chance,  then why not taking full opportunity of these instant code rendering on all possible platforms and doing it interactively as you develop your app and seeing it re-rendering on all possible formats?  

**CRAIG**:     Absolutely.  Plus, that would mean I would get to have the office where I've got an iPad and a full screen monitor.

**FRANKIE**:     Exactly.

**CRAIG**:     And 16 devices all on arms around me, and I'm floating in my hover chair.  No, I'm sorry.  I'm joking around, but I think your vision is an important and really interesting one.  I'm looking forward to catching the talk.  Unfortunately, I won't be able to make it to London where the conference is, but if anyone out there is able to go, you should because I think that's just one of the many interesting talks that all look worth going to.

I like your description, too, of the conference as being something that is not specifically focused on a technology.  I think those conferences are great.  Obviously we run a bunch of them in the form of EuroClojure, Clojure/conj, and Clojure/west.  This actually comes back to what you were talking about earlier where you bring people from different parts of the application together, right?

**FRANKIE**:     Mm-hmm.

**CRAIG**:     Like that cross-disciplinary aspect and having conferences like XT16, which, the way you describe it, reminds me of Strange Loop, which is another favorite of mine.  I think it's really, really fun, and really thought provoking.  It's just always a great time when you get smart people from different areas together and share ideas.  Yeah.

**FRANKIE**:     Yeah, absolutely.  There will be many talks from other tracks.  There will be even talks about going beyond Clojure, so there will be some debate that you maybe don't have when you just have a Clojure team conference and you have people just thumbing up Clojure and saying, oh, well, everything is good.

**CRAIG**:     Right.

**FRANKIE**:     Why not be a self-critic sometimes and maybe share experiences when things don't go that well and maybe get help from other people or other approaches from other languages?  I think these as the additional benefit of sharing approaches from other languages and other tools that maybe you don't get when you only follow a specific track or a specific team for a conference.  

**CRAIG**:     Yeah, totally agree.  Both things are super useful.  Yeah.  I go to two conferences every year, and one of them is Clojure/conj and one of them is Strange Loop.  They are both the two sides of that coin, so I think it's a great thing.

Awesome.  Well, as I tell every guest, I have a list of questions that I wanted to ask.  I've certainly asked those, and your interesting comments have suggested several more, but I also always like to make sure that we take time because I think the guests often have things that they want to say that I didn't think to ask.  Sometimes they don't, and that's cool too.  We can always have you back on and talk about other things.  We like to leave time for that.

I don't know if there's anything that you think we should cover today that we haven't.  If so, now would be a great time to bring it up.

**FRANKIE**:     I think I've covered everything I wanted to talk about.  Yeah.

**CRAIG**:     Awesome.  I certainly thought it very, very interesting.  We definitely have to have you back on.  If nothing else, I think maybe next time I'll have to pick your brain a little bit more about Tai Chi.  I just think it's a really cool thing, especially because I never realized, until some point, that it is a martial art, right?  These motions are actually the same motions that are used in the more -- I don't know what you would want to call it.

**FRANKIE**:     Fighting.

**CRAIG**:     Yeah, fighting.  Right.  They're the same.

**FRANKIE**:     It's a fighting format in the end.

**CRAIG**:     Exactly.  Just I guess to cover this after all a little bit, when I was learning -- I'm still learning -- but at one point when I was learning to play the bass, which is my main instrument, I started investigating scales.  I was doing scales.  Then I saw a suggestion to try to play them slowly, and I mean really slowly like 40 beats a minute, 30 beats a minute.  It is so hard to do that stuff well.  It's way harder to play most scales at, say, 30 beats a minute than it is to play it at 110 or something.  

I think of Tai Chi when I think of that.  It's like perfecting it and going slow.  The effect that that has on your brain, and the difficulty that it actually introduces.  

**FRANKIE**:     Oh, yeah.  Absolutely.  I think one of the things that they say is that Tai Chi slows down time, so everything.  When you take a movement or a gesture that would take a second to perform and you make it last longer, then suddenly your brain has to fill that time with something.  Instead of just performing a movement automatically, you'll have to control each part of the movement.  You will start to feel that are many muscles in your body.  

What I felt, and I'm definitely a beginner compared to people that have spent a long time studying this thing and understanding this thing, but my understanding so far is what you develop by moving slowly in that way is that you develop the small muscles, the subtle muscles that control the movement rather than the big ones, the crude one that can control--I don't know--a punch.  You will actually try to--I don't know--make the punch start from your back heel, travel through your leg, and be controlled by the waist and pass through your spine into your shoulder and then finally being manifested in your hands.  To do so, you have to consciously feel that push going forward through each of your muscles.  You will start to feel them and after a while that there are small muscles that you never thought you had and now you have to activate them.  Now your mind has to go there and make them do something.  

Well, if you only spend half a second to pick up something, then you are not controlling anything.  You tend to use the usual muscles, the easy ones that you always use.  It's sort of like a parallel to the people that always do the same things and are very specialized into something in particular that they will always be in that space.  You will always do that thing rather than discover something new, even in your body.  Tai Chi gives you the time and the patience, especially, to explore these parts in your movements, in your body.

**CRAIG**:     What's the coding equivalent?  I know we have katas, right?  Maybe I'm just not aware of it, but I can't think of a practice that is: I'm going to do something that I would do ordinarily when programming, but I'm going to do it very, very slowly.  I don't even know if that's the right transformation.  Do we have something like Tai Chi for coding?

**FRANKIE**:     I would love to find out, but I think Tai Chi is a very bodily experience.  There is a lesson.  Now a word like mindfulness, you see it everywhere.  There's a lesson about mindfulness.  We all want to be more mindful, which is basically just keep your mind there in the present and to where you are doing stuff.  You keep your mind there rather than starting to think about something else.  

They do mindful tasting of grapes where they take half and hour to taste one grape.  I find that could be interesting, but Tai Chi, for me, is too much linked to the body and really getting in touch on how your body feels and how you control your body, which normally is just a vessel for you to go from home to work, from work to your social events or whatever.  But instead, really inhabiting and living in your body and making it yours rather than just something that carries you around.  

I'll think about it a little bit more if there could be a coding equivalent, but I don't think it can just be a mind exercise.  You need to sweat in some sort of way to get the benefits of Tai Chi.  

**CRAIG**:     Fair enough.  Interesting.  Interesting.  All right, well, as so often happens, we have sort of come to the end of the show.  At the end of the show we ask our guest to share a bit of advice.  It's so funny how often we end on something that basically is advice, I think your comments there at the end are close.  But I will still ask you nonetheless to share with us a piece of advice for our audience to take away.  What advice would you like to share?

**FRANKIE**:     I think I can give advice sort of in line with what I was saying before.  I think, if you like to improve your coding, then I will advise you to move more.  It's sort of in parallel with the hammock driven development, but instead of lying down, I will advise people to go for a run.  I know it sounds a very simple advice.  It's like eat more vegetables or cover yourself when it's cold, but it's amazing how interconnected is your thinking process to the way you move your body and how much you exercise.  I think literally we have this separation between the mind process and how the brain works and how the body works.  But I think in Asia, in the more holistic way of seeing ourselves, it's all interconnected.  To have a sharper thinking, I think it's advisable to go out for a run rather than reading one more book and doing one more coding exercise.

**CRAIG**:     Yeah.  I can't tell you how many times I've managed to accomplish a critical piece of a design on a thing that I was doing, a thing that was super important to the end product while I was not in front of the keyboard.  Typically the two places that happens are when I'm running or when I'm showering.  Yeah, that's great advice.  I like it a lot.

Well, awesome.  Well, thank you so much for taking the time to hang out with us today.  When I asked the organizer over at JUXT who to have on, like I said, they said, "Well, we think we have any number of people that would be great, but Frankie is certainly one of them," and I was not disappointed.  They were absolutely correct.  It was really interesting to speak with you about these many interesting topics.  I have definitely come away with some new thoughts myself about how to just really think more about how I can spread myself around the team, both in the sense of absorbing knowledge, but also in diffusing it.  That's just one of the many cool things we talked about, so thanks a ton for coming on today and talking to us.

**FRANKIE**:     Okay.  Thanks, Craig.  It's really been a pleasure.

**CRAIG**:     Likewise.  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 is the maker 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 Frankie Sardo, on Twitter @FrankieSardo.  Episode cover art for The Cognicast 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.