“I would think long and hard about NoSQL. There are very good reasons to use it in lots of these cases, but to just using it as a silver bullet is incorrect” – Manik Surtani
About Square
– Square creates tools that help sellers of all sizes start, run, and grow their businesses.
– Square processed $50 billion in gross payment volume in 2016
– $ 452 million gross revenue in fourth quarter of 2016.
– Square manages between 4-5 TB of MySQL data on a single node
About This Episode
The fascinating Manik Surtani has joined the Devibe podcast today for an in depth conversation about some of the biggest issues in data and tech today.
Manik Surtani (Twitter: @maniksurtani | Github: maniksurtani) is a software engineer at Square and one of the leading experts on data grids and distributed computing. He is the founder of the open source data grid project Infinispan and his book Infinispan Data Platform is considered by many to be the definitive introduction on the subject. Before tackling the data storage challenges at Square, Manik was the Senior Principal Software Engineer at Red Hat.
A recent transplant to San Francisco, we discuss Manik’s globe spanning career from Sri Lanka to London and beyond. As expected, Manik has great insights on data architecture, startup growth and scaling challenges, the future of open source, and building incredible teams. Manik is an avid outdoorsman and shared his favorite rock climbing spots in the Alps and why Yosemite was a big reason for moving to California.
If you are considering a big move or just trying to figure out the best way to solve your data problems, then this episode of Devibe is a must listen.
Highlights:
- The growth and scaling challenges that motivated Manik to join Square.
- Childhood misadventures with bootleg floppy disks in Sri Lanka.
- The challenge of right-sizing backend architecture.
- Monoliths vs. microservices.
- Challenges of 32 bit intingers over MySQL
- How to overhaul mission critical code base.
- Tips for scaling your database with organic growth in mind.
- How to know if NoSQL is the right choice for you.
- The future of open source databases, including CockroachDB.
- The industry wide problem of tech debt and what it means.
- Balancing code hygiene with business pressures.
- When should a startup address tech debt?
- Learning to distinguish a code failure from product direction failure.
- The unique startup environment at Square.
- Experiments in serverless architecture.
- Cultural adjustment in morning productivity routines.
- Reverse engineering a culture of trust.
- Mountain climbing in the Swiss Alps.
- Pro and Cons of moving to San Francisco.
- Robots and wealth distribution.
—
Full Transcript
Cameron Peron: Manik welcome to the podcast.
Manik Surtani: Thank you
Cameron Peron: You are a senior engineer at Square – you’ve been here for a few years now, correct?
Manik Surtani: yes
Cameron Peron: Tell me how you made it to San Francisco?
Manik Surtani: How I made it to San Francisco….that’s an interesting story. I’m not a stranger to San Francisco, even though I’m relatively new here. I moved here almost three years ago now and having worked in red hat for a good long time, I used to travel to San Francisco a lot for conferences, for work, for things like that, so I know the city reasonably well.
Cameron Peron: Where were you before San Francisco?
Manik Surtani: London. Based out of London, traveling here for work and stuff and when the opportunity came around to actually move here, I figured why not, next phase in the adventure.
Cameron Peron: What was the motivation to join Square?
Manik Surtani: Square had some interesting challenges when I joined. Interesting challenges in scalability, reliability, trying to grow up as a company, moving away from the original experiment that was square, into a proven experiment that we are now building to scale so there were some interesting challenges in helping a company grow through those phases.
Cameron Peron: If we can just walk back in time before you joined Square, what was your first experience coding like?
Manik Surtani: My first experience coding… there were many of them… This particular story was basically back in high school. I grew up in Sri Lanka and in Sri Lanka in the mid 90s, didn’t really have proper access to the internet or computer games that were happening in the rest of the world, in the western world. There was this buddy of mine, I’ll use the term buddy quite loosely, this chap at school who had a friend or a cousin or somebody in America who would send him computer games on floppy disks. He would copy them out and share them around with everyone at school but he would password protect and encrypt them. And he would just use it as a form of showmanship that he had the keys to everyone’s computer games and he wouldn’t share those keys around very easily. So I remember actually writing something, a fake computer game, essentially a trojan horse, it looked like this new computer game he hadn’t seen before and it stole all the keys from his computer. It was kind of fun.
Cameron Peron: (laughs, ok great) And after you moved to London, school of course, what was your career like before you joined Square?
Manik Surtani: Prior to Square, I had started a consultancy in London, building, well distributing systems, highly available systems, e-commerce was becoming very very popular, late 90s, early 2000s. I was building a lot of that, job application servers were becoming a thing, they were becoming popular and widely used. I found a niche over there that really worked for me and from that I ended up contributing a lot to open source and joined the JBOS project, contributed quite a bit and someone over at JBOS said you’re contributing all these patches, why don’t you do this full time for us? That was my first job at open source and that led to JBOS being acquired by Red Hat and a wonderful career at Red Hat for a good long time.
Cameron Peron: I have so many questions about open source, but before we get into that, what are some of the craziest back end challenges you’ve experienced here at Square?
Manik Surtani: At Square? At Square, challenges have been plentiful. Like I said, watching a company grow from an experiment and prototype that grew very quickly and got very popular very fast through to making that scale as a proper company and now public company as well, the challenges have been plentiful for sure. I think one of the most interesting things, challenges we faced, we still face this even today is trying to right size our backend architecture. So we kind of went from one extreme, which was a monolith and everything was one application, to hang on, monoliths are bad, this isn’t going to scale with new lines of business and new product and things like that so micro services everywhere…and that leads to another problem which is a spiderweb of connections and makes it very complicated, very difficult to understand, very difficult for new engineers to onboard through to now. We’re trying to figure out what the right answer is, what is that right balance, a series of mini monoliths, perhaps….or….
Cameron Peron: What is the decision making process that you take into place, between deciding if you should use monoliths versus microservices?
Manik Surtani: It’s a scalability thing and when I say scalability I don’t necessarily mean software scalability, it’s also human scalability thing. One of the problems we’ve always seen with monoliths is that with a growing number of engineers committing to the same code base you end up trampling over each other, quite a lot. Despite best intentions and having a single deploy or single code base that goes out, with tens or even hundreds of commits from different people around the company, trying to work on different features, you end up stomping on each other quite often. A break in one part of the system takes the entire system down for everyone and that’s not very nice. You end up having to roll back multiple people’s work over multiple days sometimes and that doesn’t scale. So when I talk about scalability, yes there are software scalability problems as well, that have to do with traffic and load and capacity and all of that, but also human scalability thing. It’s like scaling an engineering organization, how does that happen, how do you architect your design system such that you can throw more engineers at it and everyone is still just as efficient?
Cameron Peron: We talked earlier about running out of database IDs at one point –
Manik Surtani: We did..that’s an amusing story about one of the monoliths that I mentioned – small problem – it’s the whole Bill Gates thing, 64k should be enough for everyone, right? (laughs)
But yes, this is kind of akin to that where a system was designed with 32bit database IDs and we were very close to running out and that was a scary situation.
Cameron Peron: Did it happen at a time that was like a bad time of the year or was it just…was it inconvenient?
Manik Surtani: Well….we didn’t actually run out, we managed to solve the problem before it was going to run out. But we detected that it was going to and it was a problem that was looming on the horizon. I think we picked up on it when we had a few months of runway left, so it was still fairly close, we didn’t have a lot of time to come up with a solution. Solutions are non-trivial for something like this, especially if you’re talking about a monolith which has grown organically over a few years, the original authors of that monolith aren’t around to consult, they’ve moved on, stuff that’s just grown so quickly that there hasn’t been enough time to document it and all of that, so you’re picking up on this large and complex code base that kind of does everything, it’s mission critical here and it’s going to run out of IDs and you don’t know who depends on those IDs, how they’re exploited, how they’re interpreted. This was at a stage where we had broken out some parts of that monolith into micro services, but they weren’t properly thought out (in my opinion as well) where database IDs were shared, for example, and you didn’t know where they were shared, you didn’t know what formats they were shared in.
Cameron Peron: Did you know who they were shared with?
Manik Surtani: We could tell to some degree but without diving into these multiple code bases we didn’t know how they were being treated – were they also being treated as 32bit integers, if so, you’ve got to go fix that as well. Or have they been coerced into a 64bit or a string or something else, if so you’ve got a bit more runway there. So it’s not just fixing that database, but it’s also fixing all the consumers of that data as well and how they are treating it, in some cases having to make up dates in lock step which is not easy at all. Another interesting part is that table in particular in question, the fact that it was running out of 32bit integer ids, it was a huge table. It had a lot of rows and trying to do an alter table, in mySQL, on a table that big, it locks up your database, it means that you stop being able to write to that database, full stop, for a fairly significant period of time. That’s not a trivial problem to do. So to do that, the kind of tooling we had to build around that, to let that happen in chunks and stages, yes, was non-trivial.
Cameron Peron: So what did you do?
Manik Surtani: (laughs) Essentially we brute-forced it, that was it. We ended up putting together a task force, a number of people who had mandates to go and commit to other people’s code bases around the company and we were able to analyze who was consuming that data and trace that down and make sure all the consumers now were safe, that they were all consuming or coercing ids into 64bit ids or something else…
Cameron Peron: If you were to re architect that today, knowing what kind of scale you’re dealing with today, what would you have done differently?
Manik Surtani: Oh..any number of…it’s a bit hard to say what I would have done differently because in ultimate reality…
If I was to rebuild it from scratch today, it would look extremely different. It would involve separate services and separate databases and possibly sharded databases. But that’s really hard to tell at the time because it’s growing organically, you don’t know which new business feature you’re adding in, you don’t know what additional data you’re storing, at the time of designing the system. i suppose what I would’ve designed for is flexibility so I would’ve built it in a manner that’s modular enough that every new feature, even though it’s in the same database, it could potentially be in a separate database or it could potentially be a separate service as well. And keeping those things in mind, basically.
10:15
Cameron Peron: For someone who is starting…building a database for scale today, what would you suggest they take a look at when they are architecting this?
Manik Surtani: A lot of people know SQL and move towards it, that’s been a thing a few years ago and it’s kind of quieted down a little bit now, I actually know this more than most, I used to build a mySQL database back at Red Hat, I still see a lot of value in mySQL, good old fashioned mySQL. It’s easy to develop against, it’s easy to reason with, it’s very easy to hire for – people know and understand mySQL. So then the question is, how do you make mySQL scale? If you say fine, we like the operational aspects of mySQL
and the way engineers interact with mySQL, and that’s easy to do, then how do you make mySQL scale for capacity and all of that and that’s where interesting challenges come in. State of the art, yes, you can shard things, lots of good sharding libraries out there that help. It’s something that we’ve tried to do at Square to some degree, so we do shard a lot of mySQL databases as well.
Cameron Peron: If you were to face a similar challenge in the future, would you look at like a basket of SQL and NoSQL databases, and if so, which ones would you look at?
Manik Surtani: I would think long and hard about NoSQL. There are very good reasons to use it in lots of these cases, but to just using it as a silver bullet is incorrect. As a result, I think as an engineer you should think long and hard about what your application needs. if it actually doesn’t need a NoSQL solution, you shouldn’t just be using it just because. There are cases here where we’ve been experimenting with graph databases and that’s mostly because it fits that data model particularly well and applying that same data model into mySQL is non trivial and so it made sense to do that. There are other cases where we use things like h-base and hoop and for things like that produce jobs for other types of searches that makes sense but by and large it’s far, far easier just to use mySQL for most applications.
Cameron Peron: Right. Do you think that open source is overtaking a lot of the pure vendor oriented database offerings that are out there today?
Manik Surtani: I think open source is generally on a very positive trajectory, not just in databases but ad servers and offering systems and pretty much everything, yeah it’s got an extremely bright future, but I am biased, my background is in open source. I’ve had a very successful open source project and a very successful open source career at Red Hat and yeah, you’re obviously talking to someone who is very biased about that.
Cameron Peron: What kind of open source technologies do you see out there that you think are hot or trending?
Manik Surtani: Since we’re on the subject of databases, I would say that CockroachDB is a very interesting one. I have been somewhat involved in the project in the past, not so much more recently, it’s a little ways off but I want to keep my eye on that. I think it has the possibility to change the way we think about storage. If you haven’t heard of it, it’s an interesting project which gives you a distributed, strongly consistent database across multiple nodes but still gives you a SQL interface on top of it, so it looks and feels like mySQL. And it’s strongly consistent so it will give you transactions and things like that , the sort of high level constructs that makes developers lives easier. As a developer you don’t have to deal with the edge cases of eventual consistency or trying to write map produced jobs instead of a simple SQL query which you know how to do really well. It gives you the best of both worlds. It’s built on some very interesting technology, built on ideas like raft for consensus and in terms of design, exceptionally similar to Google’s spanner which is a utility database of theirs, so yeah, it’s something I want to keep an eye on. It’s still young, it’s still growing, I wouldn’t bet my company on it at this stage yet, but hopefully soon.
Cameron Peron: Any other challenges you want to speak about that you had to face, that were…crazy?
Manik Surtani: One of the things I do think is quite interesting is complexity as companies grow, so API complexity. You have a monolith – there’s a fairly common pattern that companies start with – you have a monolith initially and then you start to break it up into lots of micro services, and then pretty often you go too far down that curve and you have too many services and now it’s crazy and you can’t remember where anything is anymore and you have overlapping services, that kind of do the same thing but ever so slightly different. In some ways that’s a good thing, it means that organizations or parts of the organization aren’t blocking on each other, if they need to go and get something done they’re just going to do it. But it means some degree of reinvention, and that’s fine as well, to a certain degree, reinventing is faster than reusing, fine I get it, but if they don’t converge, you end up with this huge tech debt problem of this very confusing and very hard to reason with set of services around the organization.
Cameron Peron: We were talking about tech debt earlier – what does that actually mean to you?
Manik Surtani: Bane of my life? (Laughs) No, tech debt is something that I wish as an industry we were better at dealing with. And I understand why we’re not, product focused companies like Square and many others, your main goal is to build product for your customers, external customers. But that often means that anything happening within your walls you sweep under the carpet and say I’ll deal with it later. The story of those database ids is a classic case. There’s only so far you can kick a can down the road before that can gets so damn big you’re going to stub your toe on it and you really have to do something. And often it’s far more expensive and far more damaging and far more difficult to do it when you’re up against a wall.
Cameron Peron: It’s a problem because it’s not something you want to do but you need to do it, right?
Manik Surtani: Well, I don’t know about that, i think people actually want to do it. I think engineers care about code hygiene and cleanliness and they actually do want to have that time to clean stuff up, but it’s just often with business pressures you don’t have the time to do that. And it’s how do we make sure we give ourselves the time to do that? We sort of create that time, saying every time you see anything that is a problem, you’re not going to hot patch it or quick fix, or sweep things under the carpet, or even if you do, you do that with a very specific plan to revisit it at a later date and clean it up and you propose that plan and you get them approved together, saying yes, I will go apply this hot patch right now but I also will come back in two months and do something else to properly clean it up.
Cameron Peron: But what is the right time to focus on tech debt when you’re in a fast growing startup, there are tons of business pressures and demands so what are the conditions for when it not only makes sense to make the decision but to force the decision?
Manik Surtani: So this is very startup-centric I suppose, but I feel that once you’ve got product market fit, you know what you’re building and you’re not experimenting anymore – that’s a very good point at which you pivot and say now we need to engineer and not build prototypes. And this doesn’t apply for a company, it could apply to different parts of a company, because just within a company you might have different parts moving at different speeds. You might have one group experimenting with a new idea, and sure, they’re going to use every hack in the book to get their prototype out there and prove something. But the moment they’ve proven it, and the moment you commit to saying yes that’s something actually worthwhile doing it’s at that point that you re engineer it and now this is here to stay so we’re going to build it properly, versus tack on more stuff on top of it.
Cameron Peron: Is it a difficulty to enforce it?
Manik Surtani: It depends. So at Square we don’t really have a culture of enforcing. It’s a very flat organization, it’s very much you need to convince your peers that it’s a good thing to do, we don’t really have a top down structure. So yes, that does make it hard, you’re right, but also at the same time not really, it helps, there are lots of smart people here, lots of thought leaders all wanting to do the right thing and having them all agree and converge on the right idea in the right direction automatically means that the right thing is happening. The hard part is to get everyone to agree on what that right thing is – so some of the details might get lost, but if everyone is generally pulling in the same direction, you’re usually pretty good.
Cameron Peron: Let’s talk about failure. Where have you failed as an engineer and also as a leader?
Manik Surtani: Where have I failed as an engineer? That’s an interesting one. I don’t…well, I mean you know individual projects (Cameron Peron: It doesn’t have to pertain to what you’re doing here at Square, anything). Right. individual projects have obviously gone sour at times and some spectacularly fun bugs have gone into production but I think absolutely. There’s one surefire way not to have any bugs out there in production and that’s not to write any code. That doesn’t happen unfortunately, but I don’t know, there’s nothing in particular that I’d like to single out. I suppose at Red Hat, with INFINIS band, this is more product direction than actual code per se, where I think we were chasing the wrong thing for a time. (Cameron Peron: What was the INFINS band product?) Oh, sorry, yes, INFINIS band is an open source data grid, a distributed data grid that we built at Red Hat and primarily used by the finance industry, anyone who cares about extremely high throughput and extremely fast performance, and distributed data across multiple JVMs it was java based.
I guess one area where we kind of went in the wrong direction there is we were trying to chase – and become a full NoSQL database and adding query and things like that to it and persistence. And the reality of it was it wasn’t designed to be a NoSQL database, it was designed to be an in memory data grid first and foremost and if you squint really hard they kind of start to look the same, but they really solved very different problems so it would’ve been better if we had carved it out as a separate thing solving a very different problem and focused on that instead.
Cameron Peron: Was the problem the product direction or was it the community’s embrace of the solution itself?
Manik Surtani: I think product direction, really. I think that there are better designs for NoSQL databases where this was not designed as one and then we tried to make it one by kind of forcing it into a different mold. And that’s never a good idea.
Cameron Peron: What was the motivation to join Square as opposed to joining an early stage startup?
Manik Surtani: I liked where Square was, what stage it was at. It had proven a product, it had found product market fit with its core being processing. And it had a few other products which it was developing, moonshots, experiments, some of which have been proven now, some of which are still very experimental and I like the fact that Square could be a mature company and a start up at the same time. That was very appealing to me – to be able to see different stages of growth within the same company, but also very interesting engineering challenges, engineering organizational challenges – is how do you build an engineering organization that spans both types of companies within the same company? That’s kind of cool.
Cameron Peron: How do you believe that twin end solutions like micro services service architectures continues will really impact the development life cycle?
Manik Surtani: I think server less architectures are brilliant, very cool things, something we’re experimenting with a little bit here, I would like to see that go a little bit further (Cameron Peron: which ones?) Just the concept, as opposed to any particular implementation, the fact that you would have everything as a discreet function, every piece of business logic as a discreet function, executed somewhere by some runtime, and you just connect them via pipes, so they look like unix pipes, but in reality using some messaging system like kafka or something. So that’s something that we’re still experimenting with and I think that’s got an interesting future, I’d like to see where that goes. But regarding micro services, that’s something we embraced early on, like I said. Mostly due to some Google DNA at square so a lot of ex-googlers were involved in the early engineering efforts at Square and built up that infrastructure accordingly. That has led to some interesting open source work as well, so we started out building an internal RPC mechanism called sakay which if you’re familiar with google’s rpc, they have something called stubby, it’s an internal google thing and handles all of their rpcs, so we built sakay and it looks sort of similar to stubby, they use protocol buffers as messages and service in points, and at one point we were about open source sakay. We got to a point where it was like, you know, there’s no reason why this has to be internal. There’s nothing Square specific about sakay and we should be open sourcing it, it’s polyglot, it’s multi language, we had worked on java, go , anything that protocol buffers were supported on basically. We hadn’t implemented it on everything yet, but it had the possibility to do that. We were also in the middle of a big overhaul of sakay, moving our internal threading libraries and things like that to neti and basically rely on neti to handle all of the asynchronous networking
Cameron Peron: Why did you choose neti?
Manik Surtani: Neti is a very tried and tested, proven open source component that handles a huge number of requests really efficiently and some of the other prototypes that we built, it was a lot faster than what we had so it seemed like the right thing to do. So we were going to go to that, we were going to open source it and we got wind of the fact that Google were doing something very similar, that they were trying to open source stubby or a version of stubby, or a clean room re write of stubby so we ended up collaborating with them and that’s where GRPC was born and so GRPC is now an open source RPC framework, it’s built on, looks and feels a lot like stubby or sakay, it’s built in protocol buffers, support for 10 plus languages, even on iOS and things like that. The job implementation is based on Neti, makes heavy use of libby io and runs on HGTP2. So it’s based on HGTP2 as the underlying protocol which is fantastic because you get all the good stuff of hgtp2, things like multiplexing over a single channel and things like that, without actually having to write all of your low level networking. Because you get hgtp2 for free today in almost any platform, so you’ve got all that stuff baked in which is great, but also because it’s a standard protocol, you have a lot of components that will support it even if they don’t today, so things like proxies, routers, whatever, they know how to talk hgtp2. And there’s a lot of cool stuff you can do with that, things like load balances and stuff. You couldn’t really do that if you were writing your own socket protocol, or you’d have to hack a lot of stuff on top of that if you were doing that.
Cameron Peron: Let’s talk about productivity. What does the first hour of your day look like?
Manik Surtani: A lot of coffee. I’m a bit of a coffee fiend, so at least 3-4 cups a day. Cameron Peron: Six is a lot Manik Surtani: Well I’m not to that level yet. It’s basically that. I manage two teams here.
Cameron Peron: Hold on, you wake up and go straight to the coffee machine?
Manik Surtani: Yes!
Cameron Peron: What time do you wake up?
Manik Surtani: I tend to be a late starter, 8am. I know California tends to be an early start culture, but I haven’t quite embraced that yet, I’m more of a night owl.
Cameron Peron: So 8 you go for the coffee machine – do you have any breakfast?
Manik Surtani: Yes, I tend to just have usually yogurt, a fairly light breakfast, I don’t go much for the big cooked breakfast very much.
Cameron Peron: How do you create an environment around you in order to get things done?
Manik Surtani: I manage two separate teams here at Square. I’m fairly close to both of them, well actually friends with a lot of people on both those teams which means we end up having lunches together, we end up having beers together after work, and I think that creates a really tight close knit bond that really helps. I can trust them implicitly with pretty much anything that we need to do.
Cameron Peron: That’s because of the time you spend together outside of the office?
Manik Surtani: It’s a bit chicken and egg, I’m not sure which came first, but yes, it evolves into a place like that, we end up forming that level of trust where I can pass on pretty much anything to anyone and I know it’ll be done right. They cover for me when I’m not around, I don’t worry about it, that doesn’t stress me out, that’ s good. I let them make their own decisions, own their own destinies, that really helps. So they have trust in me, I have trust in them, works both ways.
Cameron Peron: If you could reverse engineer that, what are the conditions needed in order to build that kind of trust?
Manik Surtani: I don’t know, I’m very selective about who I work with so that’s probably the starting point. It happens quite organically, if I like the person I’m working with, then that environment sort of happens over time.
Cameron Peron: Do you have any kind of a routine that you follow?
Manik Surtani: I tend to follow a fairly strict routine outside of work, I climb a lot, I’m a climber, a mountaineer. That sort of defines the rest of my life if you will. So with my regular – Cameron Peron: what kind of climbing are we talking about, alpine? Manik Surtani: A mix, yes, I’ve done a lot of alpine work, I’ve done a lot of ice climbing, winter climbing, but also just good old fashioned rock climbing. In the summers I just thoroughly enjoy scaling up big rocks. It’s a lot of fun.
Cameron Peron: What are some of the most memorable places that you’ve climbed so far?
Manik Surtani: Yosemite Valley of course, and that’s sort of fed into my reason for moving to San Francisco as well, proximity to Yosemite Valley or even short trips away like Red Rocks in Nevada or the Rockies in Colorado and things like that. But even when I was in Europe and flying to the Alps was my local playground – from London to Switzerland is an hour long very cheap flight and perfectly feasible for a long weekend.
Cameron Peron: Which part of the alps and Switzerland did you climb?
Manik Surtani: Mostly the Italian and French sides, spent most of my time there, a little bit on the German side but not much. Cameron Peron: I climbed in ____ once, it was fantastic.
Cameron Peron: Any other personal interests you have outside of coding and mountaineering?
Manik Surtani: Haha, too many, far too many. We got into acro yoga for awhile now, and it’s a lot of fun, but trying to find the time to fit it into the overall schedule is difficult.
Cameron Peron: Let’s talk about that – how do you make time for all of this?
Manik Surtani: Well you can’t, I’ve had to give up a bunch of things. I used to drum, I used to play the drums quite a lot, the African djembes and I haven’t touched those drums for the last few years, just haven’t had the time to fit them in.
Cameron Peron: So how do you determine what is important to you today that you want to focus on?
Manik Surtani: It’s a feel. You have a calling inside, what do I want to give up today, what do I want to keep up.
In the winter i ski quite a lot so again trying to find the time to do that. i like to kind of divvy it up between sort of outdoor physical pursuits versus the rest and I know that if I don’t get outdoors at least a certain amount of time every month then I start to get grumpy and that’s no fun. So ok I need at least this many days outdoors every month so while I’m out there I’ll either be climbing or something like that in the summers or skiing in the winters.
Cameron Peron: So what does that look like is it a long weekend or week off?
Manik Surtani: Definitely long weekends, I mean this weekend we’re off to the Sierras again, rock climbing, trying to get the last of summer in before it gets cold.
Cameron Peron: Do you go by yourself, with friends?
Manik Surtani: I have a pretty interesting community of people out here who have similar interests.
Cameron Peron: Married? Manik Surtani: Yes
Cameron Peron: So how do you find time between having I’m sure a very high pressure schedule here at Square, mountaineering, your wife, and whatever else happens on the weekends? How do you do it?
Manik Surtani: it’s a tough one, I wish she climbed, that’s one thing I could say. She doesn’t, unfortunately but yes, apart from that we do have a lot of overlapping hobbies and interests and that really helps. It also helps that she tends to travel a lot as well for work and has a similarly high pressured job, if you will, so there are times when we don’t see each other for like a week or so and then we do for quite a lot. So things like that do happen as well.
Cameron Peron: Is San Francisco an expensive place to live?
Manik Surtani: Categorically, yes. There’s no other way to answer that question.
Cameron Peron: Well, based on the opportunities you have to earn and stuff, is it really that expensive?
Manik Surtani: Well, it depends. I think if you are starting out in your career, it can be very tough. If you’re more established, if you’ve got a good job, it’s less so. Or if you’re willing to put up with a long commute and live further out of the city it’s less so. I tend to not like long commutes, I tend to find long commutes a waste of time, life, etc. I’m facetious enough to say that because I have the opportunity not to have a long commute, but if you have to that’s what you have to do.
Cameron Peron: Your commute now is?
Manik Surtani: It’s a short walk.
Cameron Peron: If you were an aspiring engineer today, if you go back in time to when you just got out of school and you could choose between pursuing a career in San Francisco or elsewhere, what do you think would be the right steps to take in order to make that decision?
Manik Surtani: i think it’s kind of hard to say San Francisco or elsewhere, that’s kind of cause grained, kind of looking at the wrong things I guess. I’m a person that tends to look at the rest of my lifestyle and where does work fit in with that? So for example, there was a fairly long time I was contemplating moving to the Alps just because and there are interesting enough engineering companies in Switzerland for example and northern Italy which would’ve worked out quite well. It just happens to be that San Francisco worked just as well, being so close to the Sierras and everything else. But, I also think that it’s kind of useful to think about where you want to work in terms of what sort of organization, what company. If the startup life is what you’re after, then absolutely yes, San Francisco makes a lot of sense. If you want to be, I don’t know, if you want to work in distributing systems, quite often universities are a good place or there are lots of other companies doing interesting work in distributing systems. There’s a little bit of a fallacy that startups have the toughest engineering problems, I actually don’t believe that. i think most startups have the toughest business problems, there’s lots of interesting innovation going on in product and business. Most of the engineering is just churning out another website, another app and if you’re good at it and can churn out stable efficient apps, sure, but if you’re a computer scientist who wants to solve, let’s say distributing systems problems, apart from a very small handful of companies in the bay area, there aren’t many companies where you can do that and you’re probably better off becoming an academic or something like that. So it depends on the motivation, what do you want to do, if you want to solve distributing systems problems, you can do that, if you want the startup experience, which is great as well, in which case, then yes, San Francisco probably is the right place.
Cameron Peron: If you want to experience a startup – in your opinion – knowing that you have your own personal interests and you set a direction for your lifestyle and you build the work environment around that, that’s great – is San Francisco the right place to pursue a career in a startup as opposed to another like startup center?
Manik Surtani: Yes, it all depends. Berlin for example, is a fantastic place for startups and if you’re into the bohemian lifestyle and electronic dance music of Berlin, then that’s where you should be versus San Francisco. London’s got a fantastic startup scene as well and I mean that was great because I love traveling around Europe, that was something, an itch I was scratching at the time for myself, and the ability to be able to get cheap flights, and it’s now a long flight to pretty much anywhere in Europe, for every weekend, based out of a startup in London, it was fantastic.
I mean, it really depends on what it is you’re looking for.
Cameron Peron: What areas in tech are most interesting to you today?
Manik Surtani: I think that AI is going to be very interesting, I know there’s a lot of hype around it and everyone’s talking about it. My, very early background was in AI, very quickly gave that up and realized it’s many years too early, but I’d like to see that happening again –
Cameron Peron: in a specific direction or in application to something specific?
Manik Surtani: Nope, in absolutely every direction. The robots are going to take over and it’s going to be fun to watch that happen.
Cameron Peron: Is it a good thing or bad thing?
Manik Surtani: I think it’s an absolutely good thing. I think it’s a bad thing if it gets mismanaged and there will be bad like small bad things happening along the way, potentially big bad things as well, but I think that overall we will figure it out.
Cameron Peron: What is a major implication or bad thing that could come out of this?
Manik Surtani: So a lot of people talk about, I mean, scary stuff, the robots will kill us or something like that because they think we’re useless. I mean that’s for the scifi books, I don’t believe in any of that. But I do think there is a growing concern that the robots will take away jobs, that they will be better at it than most human beings and that human beings will be rendered useless. Now that’s a great thing, I actually want a machine to do all my work for me, right, sit on the beach and drink rum, that’s fantastic. But the reality of it is that unless society adapts to deal with a situation like that what’s going to happen is the people who make the robots are going to make all the money and everyone else is going to be dirt poor – the investors,etc, and then you have income disparity increasing even more so. But that will lead to a situation as well where societies are going to be forced to address that, I mean people are already forced to address income equality, it’s already a problem that’s getting, coming to a head, it’s going to hit a wall soon. If we have a situation like I just described, it will be an even worse forcing function and I think the right things will happen. Whether we rethink about how companies work or how wealth is distributed, is taxation the right vehicle anymore, do we need something else, and that’s when you really get to enjoy the utopian society, you’ve got machines to do all your work and everyone can sit and drink rum, if that’s your ideal goal, how do we get there? And I think that’s going to be an interesting space to watch.
Cameron Peron: Do you see any specific opportunities in the AI that are really interesting right now?
Manik Surtani: There are lots of them. I know Google recently rebranded themselves as a machine learning company as opposed to a mobile company/web company whatever. I think it’s interesting because there’s going to be a lot more focus on it, everything from personal assistants through to just making smarter decisions because of greater knowledge and greater data and a faster ability to compute that data. You’re going to see a lot of changes across the board.
Cameron Peron: Where can people find out more about you?
Manik Surtani: I blog on Medium, not very often, but sometimes, mostly around Square related things but sometimes other stuff as well, and my twitter handle is @monxerty, same on medium.