The CTO Show

Episode 3: Florian Gilcher - CEO of Asquera

Episode 3: Florian Gilcher - CEO of Asquera

Show Notes

Things we talk about


Join Florian as OSCON in London in October!


ALI: Hello and welcome to another episode of the CTO Show. Today my guest is Florian. I met Florian a few years ago at RubyConf Uruguay and we've been Twitter friends ever since and I think we share a lot of similar interests so I thought it would be interesting to get him on the show. Hello, Florian.


ALI: So what is it that you do, Florian?

FLORIAN I do a lot of things. Mostly I run a company in Berlin that does consulting for backend services and databases. I do run community events on the side so I’m often to be met on conferences to also check on what other people do. I tend to use that for travelling and this being how we met when I took the chance of speaking at RubyConf Uruguay.

ALI: Right. You don't do the actual consulting at the company, you are more kind of going and engaging with the community and publicising it?

FLORIAN No, I actually do a lot of the consulting so I’m currently on a consulting gig somewhere else - I’m not in Berlin currently - so I am still doing all the jobs.

ALI: And how much of your time, because you said that you run the consultancy, how much of your time, would you say, as a percentage, is spent actively working on client projects and how much would be on doing everything else required to run the company?

FLORIAN Usually it's around 80% of the time actually spent on clients’ projects.

ALI: Okay, right.

FLORIAN The usual deal that I have with clients is Monday to Thursday I’m yours, expect like a couple of emails or something like that, and on Fridays it's running the company.

ALI: Okay, and you run it with your brother, is that right? Maybe it's your brother, I just noticed you have a similar last name so I guessed as much.

FLORIAN Yeah it's actually my brother.

ALI: Okay, cool. It looks like you've grown the consultancy beyond just you and your brother. You've hired a few developers - how has that process been for you?

FLORIAN We've hired around six people now as developers. The process has been interesting - at the beginning it was mostly friends and then community members from around Berlin. We recently started working with student people, which is quite interesting for a company that does consulting, so we sell knowledge so it's rather tough to send the clients people that are not as experienced as they might have expected when they start talking to you. On the other hand, I think a lot of the tasks that we do can be done by people with less experience than we have if you give them guidance.

ALI: And what has that process been like? In particular working with junior developers. I run a consultancy as well and it would be very difficult for us to charge our usual rates that we would charge for an experienced developer for a junior developer, for example, just because, like you said, the tasks that we have, we can find things that they can do, but we can't let them do, for example, the strategic level conversation with the client and that's kind of really what they're paying for. So how have you managed to keep them from that conversation with the clients?

FLORIAN Well first of all we do charge a lesser rate for people that are at junior level and we always pair them up with experienced people so they're never on a job alone and we're pretty clear that if there are any questions on strategy and things like that, talk to the more senior person, probably try to have a conversation in a group so that the junior person can listen in and maybe have an idea, but we just send people as a group and never alone.

ALI: You mentioned that you do a lot of community stuff. Can you talk about that for a bit?

FLORIAN I've done community stuff for more than fifteen years or something. I actually started monitoring bulletin boards when I was 17. Back then we were talking about metal and music mostly. The board has since been closed down. After that I started programming Ruby for some weird reason, I actually flipped a coin between Ruby and Python.

ALI: Hilariously that's kind of the advice that I give to junior developers - you can just flip a coin between those two languages because they're so similar in the level of instruction they're at that it really doesn't matter, and people will try to convince you either way. You really flipped a coin? Like you had a physical metal coin and you flipped it and made the decision?

FLORIAN Yes, yes.

ALI: Wow.

FLORIAN At university one of my flatmates was really interested in languages and recently wrote a PhD on the Haskell compiler. I wanted to learn some other language besides the stuff you learn at university because that was quite boring, like that Japanese language where everything is an object, no one knows it, stuff like that, because I didn't want to use the language for anything useful. I flipped that coin and ended up with Ruby and one year later someone came up with that thing called Rails.

ALI: Yeah, that you love so much!

FLORIAN I do still like it, it's just for the kind of jobs I do it's not the best piece of software.

ALI: Before we started recording this episode I had a quick look at your company blog and I noticed that there is an often repeated tweet, something like 'In every web application that starts with Sinatra it ends up containing a buggy, partially implemented version of Rails,' and then you wrote not a long but an in-depth post about how detrimental that is and how it's not been your experience at all when working with things like Padrino in the spirit in which they were intended, so yeah I found that interesting.

FLORIAN It's a little bit of a problem in the Ruby community that they focus on Rails so much and that they think Rails has solved everything properly, especially if you're doing anything that has to do with specialised backend services or these kinds of things it's probably not the best pick. It's still a trend to pick for quickly writing a rich website with interaction and everything, it comes with everything, you don't need to think about a lot, you just need to use it as intended and then it's a really powerful framework, it's just not the solution to all problems.

ALI: Yeah, if you were a PHP developer, I don't know, maybe 10-11 years ago, and then Rails suddenly landed in your lap it would be the solution to literally all of your problems, but in 2016 we implement a lot of things that aren't basic applications and it's definitely not the best thing for, for example, running an API or having a very small service where you want a really small memory for print or something. I'm kind of in agreement with you there, I think.

FLORIAN After that I picked up doing basically the same - I moderated a bulletin board for Ruby for quite a while that a good friend of mine runs and after that I started running events, basically first of all for meetings of the board, so we went to a Hacker Space in Leipzig and had two meetings of around twenty people year after year, and at some point in 2012 a friend put out a call that he wants to run another Euro Camp which was a spill over event for the Euro Co that happened in Berlin - there were too many people that wanted to be on the conference than they could sell tickets so someone just ran a second event on the same weekend.

ALI: Wow.

FLORIAN That was how Euro Camp started and I was involved in Euro Camp for three years. It's known for being special; it's always outside of Berlin, next to a lake, instead of being inside of town. It was in summer instead of being in autumn or spring so we had to deal with the conference is hot, people might not want to stay in for the whole day or something like that which, if you take that as constraints, can make the event really, really special so a lot of people love it and it has stayed a rather small event.

ALI: Okay. I had it in my mind that it was a really big event for some reason.

FLORIAN Well it's 200-350 people.

ALI: Okay, as far as conferences go that's not enormous, yeah.

FLORIAN It's also in high summer so a lot of people are on travels and away with their family and things like that. It's always nice to have events that are not that large and not that easily sold out because that means that you usually have people around that have to think about buying a ticket for two to three weeks and things like so I do enjoy that a lot.

ALI: I think the last time I met you we spoke about it briefly and one thing that kind of stood out was the idea that you had day care and activities for the families of the attendees, for their spouse and their kids, which I’ve never seen been done at any other conference.

FLORIAN Actually, to admit it, in 2014 the activities for spouses hadn't worked out that well, it was a bit of organisational chaos.

ALI: Right, but points for trying I guess!

FLORIAN Yes, but the 2015 team, which I was not part of, was much better in a lot of these aspects. Day care we definitely needed because if people have to go outside of town they can't just send their kids somewhere, to maybe just go visit a museum or something like that.

ALI: Okay, yeah, as a dad I don't think that's one of the options, just sticking them in a museum and hoping for the best.

FLORIAN It also wasn’t very hard to organise. A lot of these things, like day care, you call someone that does professional day care, you ask them for a quote and then you just make sure that you have a room at the conference location and usually most hotels are quite okay if you say you would need a little room for three to four kids - it's not that many more that will attend. They’re usually quite open to that so I think a lot of conferences that think they don't want to run one of those things because of the effort involved basically never tried. So a lot of these actions are pretty easy to do.

ALI: Aside from the actual effect of allowing people to have kids to come along it also sends a very strong message, I think, when you're considering whether or not to speak or attend a conference, about the kind of conference it's going to be. Like you wouldn't, for example, see the big, I guess, industry - when I say industry I mean the start-up ecosystem conferences with thousands of attendees and headliner speakers - I don't think you'd ever see day care at those conferences, whereas if you went to one of these conferences that we run in the development community and it had day care, which would seem a bit more likely, it feels like a much more welcoming and much more appreciative that developers have lives outside of work that need to be accounted for so I think it's a really good thing.

FLORIAN Yeah, also a lot of the attendees have a really positive reaction towards it. There’s a lot of 'I wouldn’t use that for some reason but it's nice that it's there and I do enjoy that other people can use that.' Also one of the criticisms you have towards those things is that it's basically something for a special interest group and some people argue that the money that comes from ticket sales and sponsorship be spent equally on all attendees. In my opinion that doesn't work anyway but from the people that actually attended feedback was usually perfectly fine that money went towards this because they liked to have those people around. It's a benefit towards all.

ALI: So one thing I don't understand, because I know a couple of people who run conferences and the explanation I’ve had has been varied - in the case of Euro Camp, was it under a registered charity or is it a for-profit thing run by a company? What was the structure of it, legally?

FLORIAN Euro Camp was run by Ruby Berlin which is now a registered non-profit. It used to be created for the Euro Co conference and it wasn't a registered non-profit back then but it was an independent association.

ALI: Right, okay.

FLORIAN I don't know how that is in the UK. In Germany we have that non-profit has nothing to do with the organisational form so you can have a non-profit company.

ALI: I see. The reason I ask that is because obviously that puts into context the complaints you were hearing. If it was a private company, saying 'We don't like the way you spend your money,' the answer, obviously, to that is 'So what?' but I guess if they have some stake in it because it's a non-profit then perhaps, yeah, I can see why they would start complaining about that, but at the same time I think human beings that reproduce is a big enough group to account for that it's kind of okay, right?

FLORIAN Yes, that's right. As I said before, it sends a message, and that's something that we did in the last Euro Camps much more than before. For example, one of the things that we advertise and we talk to other conferences about a lot is documenting the accessibility of the venue for people that have any kind of accessibility issues in the broadest sense and it definitely shows if you put a text on your website and say 'By the way, we have a venue that is wheelchair accessible, we care about people that have problems with hearing,' and all that kind of stuff - which is, again, really simple to do - if you book a venue just ask them if they're wheelchair accessible and if they’re not just go to another venue. It should be standard. Sadly, in Germany, it's much worse than in the UK. In Germany it's pretty hard to find a wheelchair accessible venue that doesn't bullshit you on their status but if you put the word out that this is something that's going to happen at your conference people will look out for it and will attend. That’s the other thing that I often hear - 'We're not excluding anyone, why are people not coming?' YEs, but the problem is that maybe they had a bad experience at an event before so they wouldn't consider that tithings are different at your event and if you don't properly document what's there and what's not - sometimes you can't provide for something and if you don't properly document what's there and what's not these people will not attend.

ALI: And even if they can't attend because of something that you've documented - you've said 'We don't have this particular kind of access,' then at least they can make an informed decision, rather than turning up and having a bad experience and then not going to an event ever because of that. I want to go back a little bit to talk about your company some more. How much of your role would you say could be described as management or leadership? You’ve only got 20% to work with it!

FLORIAN That's a lot of bookkeeping, marketing and sales these days. I try to be on all of my projects with some of my employees so there's definitely leadership involved on those days, deciding what we're going to do, making technical decisions, and most of the time I’m also taking the communication part, so discussing what we're going to do with a client and all these kinds of things, because for many reasons I would be involved anyway, so if one of my employees discusses with a client and doesn't deliver I would be the one that has to talk to the client anyway so it's probably best if I do that first, so it's definitely in that range.

ALI: In our situation we kind of have the developers being the single point of contact for the client, so they handle everything, all of the communication and all of the requirements gathering, and my job is to basically catch any exceptions that that process throws, so if there is some situation where the developer doesn't feel empowered to do or make a decision in terms of the engagement or there's a complaint the client has that they feel would be more appropriate going to me than to the developers then that's where I come in, but for the most part I am not there in the day to day for the client projects - which, for me, was very, very difficult, to get to that stage, because they own the relationship. It means giving them a level of autonomy that I was very uncomfortable giving them, knowing that my name or my company's name would be on the end product.

FLORIAN I'm actually comfortable with that. We do have some projects where this is not happening in that sense, so we do have projects where we do have the developer as the direct point of contact and that's mostly clients where they have a large management anyway so we just give them people who have experience in a certain area but they're usually absorbed by the team there. Then I usually also expect from the client that they know to manage the team and all issues within the team but sometimes on projects when we do a lot of consulting on rebuilding certain aspects of the system and onsite stuff with those groups, and if I am within the team it's also usually me doing a lot of the talking.

ALI: It says on your website that you're backend specialists, including consulting on things like Postgres, Elasticsearch and other data stores. Can you talk a little bit about that offering? The reason I ask is because we are a really, I guess, vanilla Ruby on Rails, CRUD application development shop with a little bit of JavaScript sprinkled on top, so I’m just interested in the structure of an engagement where you're just consulting on, say, Postgres. What does that look like from the client’s point of view?

FLORIAN Usually it's people calling us for specific problems with their database. For the last few years, actually, it used to be mostly Elasticsearch when it comes to proper issues because, for some reason, there is an Elasticsearch users group in Berlin which used to be one of the largest and longest running Elasticsearch user groups, so there’s always that community aspect. That's the kind of work we're known for, currently, and the way it works is that usually clients approach us, 'We have a specific problem with our cluster,' or 'We've been running against the wall for three months now and we just need someone to have a look at things.' That’s usually how most of the engagements start. Maybe to backtrack a little, the reason we started a backend company was that, first of all, we had a certain interest in that and my brother and I just started as two people and then we started a company two years later and we always enjoyed taking that part of the system and making sure it was better towards the frontend applications. So the general idea of the company is we do everything where data flows. If you really need it we can also build the backend part of your JavaScript application, basically just the part that speaks to your backend systems, no CSS stuff involved, and it's a pretty interesting place to work, especially because of the structure of the projects we get because we rarely start out at the beginning of a project. A lot of companies don't think that backend is something they need to solve at the beginning so when we come in usually most of the decisions are already made so it always takes some analysis on what was decided, why and how was it implemented later. So it's a lot of analysis and it's a lot of being flexible on what the client works with. If I do the Elasticsearch part, I can't choose whether they use Spring, Rails, Elixir or something so we usually also don't sell our offers on programming languages and then we come in later and a lot of the time it's fixing stuff instead of building the stuff from the beginning.

ALI: So it sounds like what's happening is you have, like you, a kind of analysis phase for many of your projects which then may progress into fixing their data store stuff but then not necessarily work on the programming side of that. Does that sound about right?

FLORIAN We also work on the programming side but pretty often, yeah, it's giving a hint on how to properly work with the data store in question, maybe writing the client for it, maybe writing samples for the development teams that they can later evolve, but pretty often the goal is not to be engaged all too long there.

ALI: So you've been going for how long? In this sort of format and specialising in this.

FLORIAN A little more than three years.

ALI: Okay, and in that time, in the kind of, as you described it you work on where data flows, what have you seen or have you noticed any patterns or trends in the biggest or most common mistakes that people make?

FLORIAN Yeah, quite some. I think the biggest mistake is really not thinking about the backend early enough or not considering it as important and not following many best practices there. The biggest problem I have is that a lot of the time people in teams don't have any experience with database optimisation or database behaviour at all so what happens if I put stuff in there? For example, Elasticsearch has a pretty particular behaviour if you use it for searching which is the way you query Elasticsearch is pretty much bound to how you put data in. There's always these two phases - you analyse data before putting it into Elasticsearch and then the way you query it is highly dependent on the previous steps you did. That’s something that a lot of people are not aware of and sometimes I think it would have been better if they had just asked for someone to be there for the first two weeks of the project instead of after they went life and want to optimise the stuff. The second pattern is not wanting to change the database just before launch or before launch. The problem with databases is any kind of rebuild of your data structure in a live environment is much more costly than in your development environment because suddenly you've got all of these things like uptime to think about and you can't just change a database schema with no downtime, no planning and no work before that while redeploying your frontend with new code is, in modern architectures, extremely easy because you just restart the docker container with the new code and you're done.

ALI: Right.

FLORIAN And so a lot of the architecture changes lately have pushed a lot of this uptime complexity, like how to keep the stuff running while doing the hard part, except on the data store level.

ALI: That, to me, I’m not really up to date, I guess, with the most modern ways of doing things with databases but I don't think I’ve seen anything that, as you say, solves that particular problem, being able to replace your data store with some other data store without any downtime whatsoever.

FLORIAN There are techniques on how to re-annex your data, all of these kinds of things, with little to no uptime but it still takes a lot more preparation than in the beginning, during development, where you can just say 'Okay, I’ll just change my schema, just change my mapping file and just throw away all the old stuff.' That’s the advantage of early development - you can still throw away the old stuff without blinking and once you launch you can't. You can't throw away a user's database.

ALI: There have been a lot of posts for a layman in this particular topic recently that have been quite good. I think there was a post recently by the engineering team at Uber about how they moved from PostgreSQL to MySQL and it went into a lot of detail about the inner workings and behaviour of, I think, the Wire protocol and how the representation on disk was accessed and how it turned out that InnoDB and MySQL turned out to be better and more performant for their requirements than PostgreSQL was. So, yeah, that should be a pick, I guess. But I was wondering have you read anything like that? Have you read that post?

FLORIAN I haven't read the post yet although I quickly skimmed the commentary and I think one of the best comments to that is always 'You’re probably not Uber.'

ALI: Of course, yeah.

FLORIAN But it's still important to be aware of how much you can do on that side. I think that's another thing I see far too often - people optimising for high performance far too early instead of opting for stability. For example, one of the things I found interesting was there was that moment where MongoDB was hugely popular and basically any start-up started using MongoDB. We got quite some people that asked us 'Okay, you do know SQL stuff, do you also have experience with MongoDB?' and we didn't actually have it but once they ran into problems they were searching for people that were experts in MongoDB but the problem is, if the technology is new, there are no experts on the consulting market and even when it comes to Elasticsearch it is, I think, six years old now or something like that and only now do we start getting a dedicated Elasticsearch consulting market. Before that, basically people handed me jobs like 'Okay, I met you on a conference,' or something like that, and only now we get asked by, I don't know, hiring agencies or job agencies and if I speak to agents of job agencies they're like 'Oh, yeah, that's that kind of new stuff. I've heard of that.'

ALI: I'm interested to hear your take, because I also deliberately tried not to bring up MongoDB from my side in this conversation, I was waiting for you to bring it up. I was wondering if you had any thoughts in general about the applicability of MongoDB to the general case, without giving you a specific usage, just the way you've seen it being used. Do you think that most uses of it have been appropriate?

FLORIAN That’s hard to say because pretty often I’m not consulting on MongoDB. Sometimes I’m throwing it out because people try to use it as a distributed search engine, which it's just not good at, which is actually not part of the base technology it's just the problem is a lot of people, when it comes to Elasticsearch, are not aware of what the problems and particularities of natural languages are like and that tends to be a problem and people just set up MongoDB search and then they call you and you're like 'Yeah, for your particular use case it's just not the right tool to solve the problem.' In general, as a database that has near real time behaviour in summing up data and things like that, it's a pretty interesting piece of software. I know a couple of companies that use it for data that want to push it in as fast as possible and if the whole system fails and loses data the event is so catatonic that there is no use in recovering the data anyways.

ALI: So what do you mean by catatonic?

FLORIAN For example, I know one company that uses it for tracking calls that go through a call centre, so if the system goes down all calls are dropped anyways so they don't care if they are persisted in the database or not because it's down, the calls are dropped.

ALI: So it's all about the speed of rights and not really, in this particular use case, worrying too much if you lose a whole chunk of records out of the database.

FLORIAN Exactly.

ALI: Yeah, that particular use case sounds like a lot of stories I’ve heard about MongoDB except that they wanted to keep the records and didn't care that much about rights speeds. I, as yet, have not heard of somebody saying 'We use MongoDB, it turned out great,' but now I’ve at least got one story where I can tell people that, yes, it's good in this use case.

FLORIAN By the way, there is a database that is far more often misused in that sense.

ALI: Really?

FLORIAN That's Redis. People use Redis as a back buffer queue for a lot of things and the problem is that Redis, by documentation, if it runs out of memory it fails and loses all data, which is fine, that's the way Redis works, but people use it as a queue in systems like the log stack, as a back pressure queue for their log data, then they suddenly find out that if their log indexes fail and the connection to Elasticsearch fails, everything queues up in Redis and it just blows up and the way this piece of architecture should work is if the parts behind the buffer fail it should just keep as much data as possible until the rest works again and the systems that are explicitly written for that, for example Apache Kafka or things like that, people still use and recommend Redis until it blows. That is something where I am 100% sure if I go to a client that has a log stack they usually have that story that they used Redis until it blew up.

ALI: Okay, wow, I’ve never heard a bad story about Redis before. The thing that I’ve found so far and I guess your clients have much bigger requirements in terms of data or much more varied I guess, much less easy to solve with off the shelf tool problems, but basically Redis, my understanding and how I’ve always assumed to use Redis when putting it into production in any application has been that it is just a skin, an API over the top of the random access memory available to me in that particular instance or whatever, and the minute I put data in I will get it out again while that is still up, but if I restart that server, as far as I am concerned that data will no longer be there. However, I have discovered that Redis is actually quite forgiving in this regard - it will hang onto things and it does actually put things back, like on disk, without me telling it to and for the most part it's been quite forgiving in any situation we've put it in as a disk backed store as well as just being a memory backed one so it's interesting to hear that it does actually blow up and it's not particularly useful as, like you said, a back buffer queue. I think the author of Redis has actually made a different application that is supposed to be used as a queue. I'm not sure how it works and I forget the name off the top of my head now but I think he put a solution in that area out there. Do you know what it's called?

FLORIAN I forgot the name too.

ALI: Okay.

FLORIAN I haven’t used it in production anywhere. We basically moved to using Kafka for a lot of these things. A lot of people think it's overblown.

ALI: So Apache Kafka, what is it exactly?

FLORIAN Kafka is basically a messaging queue that's just built for forwarding messages somewhere else so it doesn't do a lot of fancy stuff except the clustering so it's built for being persistent and very forgiving towards the hardware that's below it and one of the nice things about Kafka is that basically the Kafka system itself doesn't track what is in and out of the queue, it basically just writes to disk. What tracks what has been read are the clients. So for example if you have some reason why you want to read the last hour again, for example, because you changed your log stash filters and it turned out that the way you did it dropped some data that you didn't want to drop or something like that, you figure that out in production, you can still say 'Okay, let's rewind by an hour, let's get all the data again out of Kafka,' so forwarding a huge amount of data like logging usually does it, Kafka is a really good solution.

ALI: Yeah we got quite deep into the tech there which is not normal where this podcast ends up going but that's fun. In terms of your business and the direction it's going in, right now what would you say where your one or two biggest challenges that you're facing?

FLORIAN There’s always the ongoing challenge that backend has a problem in selling. I just can't show people my previous work.

ALI: Right.

FLORIAN I can tell them I used to work at this company and I used to work on their database but I just can't give them access to that database so that they can have a look at my work, so there's a lot more trust involved in saying 'Okay, we've got an iOS application, you can have a look there.' Sometimes we have a problem - I built a backend for an iOS application that I don't really want to show around. The backend is really, really fast and I really like the technology behind it but I don't enjoy the application at all so I usually don't hand it to people.

ALI: Can you give an indication of the general, I guess, genre of the application or would you prefer not to say?

FLORIAN It's an application for a TV show.

ALI: Oh, it's for a TV show, right, so the technology behind it is great but you don't really want to tell people that you worked on XYZ TV show.

FLORIAN Yeah. I did enjoy the application by itself. It doesn't look like a very interesting iOS application. You are not the company implementing that, it's usually some other agency and you don't have any control and I don't want to comment on why the application wasn't the way I would have imagined it to be or something - I can't, I wasn't involved in the project at all - and also what would any client deduce from that? The only thing they can have a look at is 'Oh, the data loads, that's great.'

ALI: Could you write up a case study that says 'This was the problem and this is what we did to fix it,' without really talking about the details? Just using the company name as opposed to the particular application that you worked on.

FLORIAN Yeah, I could do that, but that would mean stopping implementing a lot of this stuff, so doing more marketing and stopping implementing at some point.

ALI: It sounds like the community stuff has gone quite well for you, just using that to build leads. Is that accurate, do you think?

FLORIAN I can imagine more effective parts but I couldn’t imagine a more fun part.

ALI: Okay, right.

FLORIAN I love the community work so it's definitely good that I can also use that as a sales channel. Especially conferences tend to be a lot of work so running a conference is probably, if you're doing it in a small community-focused, non-profit fashion, probably not the way of selling what you do as a company, and especially because conferences also have a problem that there isn't much fame, as a person, in organising one.

ALI: Yeah, I guess speaking at one, or speaking at more than one, definitely. Just that one conference I spoke at has given me a lot of business opportunities. I haven't actually spoken at a conference since. I know from personal experience that that works out quote well but, yeah, organising one, I’m not sure that gives you much in the way of that fame.

FLORIAN Well you should talk more, it was an extremely fun talk.

ALI: Oh, okay, thanks!

FLORIAN The other part is that I just hate writing down a lot of things in a fully finished way, so that's one of the issues I recently tackled by having a small sub website that is not my blog that is basically just for random notes.

ALI: Okay, yes, I think I saw part of this. We should include it in the show notes.

FLORIAN Yeah, it's where I usually just dump stuff that I’ve just recently figured out - 'This is the pattern you can use, this is something else you can use,' so documenting aspects of my work or insights in a non-structured fashion which makes it far easier to just dump it and at some point come back to it. I think the biggest problem for me is it is you want to finish a blog post before publishing it and then you don't want to fundamentally change it later because it has a publishing date. Maybe you want to de-publish it and write something completely new. So I am currently experimenting with basically having a document where I can't guarantee that tomorrow it's looking the same as today.

ALI: I've struggled with this and I think for me the biggest jump was realising that the first draft of the post, even when it's finished at a thousand words or whatever, doesn't actually at that point still guarantee that a post exists. You have some content and whether it can actually be turned into a post that is useful for anyone at all to read actually ends up happening in the editing and that's a lot of work so, yeah, I have a sketch file where basically I will write maybe a couple of hundred words a night and then, after two weeks, maybe a post will exist based on the bits and pieces I’ve written but I just can't sit down and write out a post and publish that, I just don't feel the motivation to do that on a daily basis so it's difficult. The other thing I wanted to talk about, because we're running a little bit short on time, was Rust. Can you tell me a bit about how you got into Rust, why you like it and what your experience has been of it so far?

FLORIAN That's my recent community project, so I’m a member of the Rust project as part of the community team, which is kind of weird - I’m basically doing sales for Rust, although I think I’ve made it clear that sales is not the thing I like the most. The thing I like about Rust is, first of all, they value community work, which is surprisingly rare in programming communities. Often, if you see people debating about why a technology, especially a programming language, is successful they rarely talk about the people that early on went and talked at conferences, ran a meetup and things like that. The way I found Rust was basically the same way I found the other technologies, Elasticsearch and Ruby, basically at random, I just downloaded it. I often try things out for an hour or two or something like that. The thing that took me with Rust was I never had a chance of seeing a programming language grow to release because usually people work on a programming language and then they release it at some point and then it's done. The interesting thing about Rust was that, at the beginning, I started with Rust 08 two years ago and basically it broke all the time but it was cool because you could see why people broke things, why thing changed things. The syntax was completely different but, at the same time, that was something that I found interesting there, that people were already at that point caring about how it breaks so there's always a way that people currently trying out the language know how to port their code over to the next version.

ALI: When I tried it a while back occasionally you would just find little bits of syntax that were weird or were a bit onerous and what was interesting was I would Google it and somebody else had found the same thing and there was an RFC on GitHub about how they were going to fix it and then it was like 'Oh, okay, they're going to handle this problem in the next version and it will be better.' I kind of liked, like you said, watching that process happen and being maybe five or six months behind it but still being able to see that, okay, they know there are issues in it and they're doing things to make them better was cool.

FLORIAN Also the compiler has a lot of machinery for that and back then that was incredibly cool because they basically followed the idea of the compiler to text that if you’re trying to use a pattern that is not in use anymore it will tell you what to use now so if you compiled your code every weekend you basically got your little bit of homework on these kinds of things. But now that Rust is released I’m heavily pushing towards people, please, actually use the stable Rust version because I think for industry adoption and for production adoption people need to see that you can write proper and good, stable software in Rust, which you can, and every kind of new fancy software that doesn't use the stable Rust compiler basically pushes the needle a bit towards 'Oh, that's going to be the language for the next year.' I'm convinced that you can actually use it in production properly, although the topic that you may use it for may be fringe currently so you should pick it well. But it's an incredibly welcoming community that values a lot of aspects that are usually undervalued and the other thing that also played a part in it is at that point I decided that I’m not going to learn another programming language for the time coming because I don't think it's a good strategy to learn eight, ten or more languages.

ALI: I'm totally in agreement with that.

FLORIAN Learn about your database more.

ALI: Or learn about operating systems more, yeah, there's so much stuff that I think is more valuable once you have a general purpose scripting language under your belt, especially now that I get older and I feel I have less time to learn things, so if I’m going to learn something - this is one of the reasons I wanted to learn Rust - it's going to be something that is, on a paradigm level, completely different to what I already know, it's got to have some kind of value to me, either in what I’m going to learn from it or the kind of software that will allow me to write, and I think that's where I lean towards with Rust is I can write much higher performance software in Rust than I could hope to ever write in Ruby and I don't have to think too hard about it, like I have to learn about borrowing and ownership and all of that stuff but that's not as hard as being very, very careful about counting errors in C and things like that so I think that's one of the reasons I like it.

FLORIAN Maybe I’m just projecting there but I think that, while I started to constrain the time where I learn new stuff outside of my work time, I have the feeling that I got much more efficient at it so I’ve recently picked up a lot of things outside of my job and my study topic. So I stopped doing a lot of IT stuff outside of work and picked up other stuff and I feel like the time I spent with the IT things was much more active. So I don't even know if I’m learning less than before.

ALI: I wanted to mention a quick thing before we continue - the thing you mentioned in Rust, the community being better, I think that's actually really, really value. I should be clear that my local Ruby community is great, but I’ve seen more than one conversation in the Ruby core contributors or whatever mailing list they use to have discussions about things they want to change about the language, I’ve seen more than one totally dysfunctional conversation. There was one recently about, I think, the way they got random bytes depending on the operating system and the discussion there, they were talking over each other's heads, and people might argue that's a language barrier issue, I really don't think it was, and I say that as someone who speaks Japanese and has spent a lot of time with people who speak English as their second language who are of Japanese origin and that didn't seem to be the case, it just seemed like they weren’t used to having productive discussions. I think with Rust, you can just go and look at their RFC system, you can watch these discussions happen and, yeah, they have ups and downs, I guess, but most of the time it's very constructive and obvious that people are trying to work together to actually build something good so I think that's where Rust wins a little bit over Ruby.

FLORIAN Yeah, I think so, although I have to say my theory about the Ruby community is there is no Ruby community.

ALI: A good theory!

FLORIAN That’s the thing I really enjoy about Ruby, that there's a substantial part of the community that is Japan where I, as someone who doesn’t speak Japanese, can't speak to, it's an incredibly interesting part. One of the things I like about the Rust community is that they have a lot of people who know how to argue their case very well without getting insulting. There’s a lot of decisions that people still don't feel are right but usually the conversations around them are really, really respectful and I think that also makes it far easier for new people to actually suggest something for the language and we have some RFCs that come from people outside of the Rust core team that show meaningful new ways of how you can do things and they're always very well handled and we also optimise for making the experience of new people as smooth as possible, also partially by automating it. That's another thing I find interesting, is how much of a community can you automate? For example, one of the automations that we have is if someone sends a pull request to the back tracker there's a bot that basically just works by assigning someone to that pull request and that's a problem that a lot of projects have, and I used to groom the backtrack of Padrino, that pretty often pull requests don't have someone that takes care of them and the simplest way you can solve this is basically just assign one random maintainer to it and if they can't review that properly because it's not their area of expertise at least their immediate job is to assign a person who knows and that makes sure that new stuff is worked on pretty early and now we have a problem that this timeframe tends to get bigger and bigger as the project grows so we're currently thinking about new ways of making sure that new people get served as quickly as possible.

ALI: Okay, that's interesting.

FLORIAN That's how you keep them around.

ALI: Okay, so you would weight it towards people who are new to the community so they feel like their contribution is being looked at?

FLORIAN Yes, because they don't know nothing about the community. I think that's something that a lot of people forget when they do community work, is because they're on the inside of a community they think it's nice, they've probably got their position, you've got a name in the Ruby community so people treat you nicely and all these kinds of things. If you're new you don't know nothing about this, you don't know if people will be nice, you don't know if people will be jerks.

ALI: Like you said, it's interesting that, in Rust, people have realised that if they optimise that first touch experience they know they'll be able to attract more people into the work.


ALI: So, yeah, we've gone massively over time. I want to ask you, before we finish, what your picks are for us.

FLORIAN My problem is I don't consume a lot of media. Usually I consume conference talks and one of my favourite ones that I want everyone to see is 'A Short History of Software Engineering' by Paolo Perrotta that just, I think, explains a lot of the ideas behind how not everything is broken and it's amazing that all of this stuff works. It's a pretty high level talk, I definitely recommend it. It was held at Baruco back in 2012 and I rewatch it basically two times every year.

ALI: Wow, okay.

FLORIAN The next one is 'Will the Real Technical People Please Stand Up?' by Leslie Hawthorne, who I respect very much for her work and especially for her talks, and it's about who's technical and who's not and how that really doesn't make any sense. That was held at Euro Camp, although not at one where I picked people so kudos to that team for picking that one. And the final one is a website that I pretty often browse. I like listening to music and I like listening to live music and has a live music archive so it's not just a way back machine where you can have a look at old websites. They have a video archive and a live music archive and there are a couple of bands that are extremely bootlegging friendly and are allowing people to bootleg their concerts and it's all legal so you can have a look at where the band said that taping the concert is okay and you can have a look at that. I highly enjoy that; I just browse through and find new bands and all of these kinds of things.

ALI: Awesome, those are excellent picks, thank you. Thank you very much for coming on the show and taking the time out of your schedule to record this with me. I've had a lot of fun and I hope you have too.

FLORIAN By the way - one final thing - I’m rarely in the UK but I’ll be speaking at OSCON. OSCON is in London, the O'Reilly Open Source Conference.

ALI: Alright, okay, and when is that?

FLORIAN Mid October. I forgot the dates. I think it's the 10th or 12th to the 14th or something.

ALI: Okay, awesome. So listeners, if you're in London you should go to OSCON and you should listen to Florian speak.

FLORIAN Excellent.

ALI: Alright, thank you.

FLORIAN Thank you for having me.