Getting to Know the Keep Team: Antonio
Welcome to our team interview series, starting with our Tech Lead Antonio Salazar Cardozo
Laura: Hi Antonio, we’re excited to be kicking off our “Getting to Know the Keep Team” series with you, our Tech Lead for the Keep Project. Could you start us off by telling us a little bit about yourself and your background?
Antonio: Of course! This kind of question actually drives me crazy a lot of the time — you have to pick and choose the facets of yourself that you want to present to the world. I’ll go with the standard pitch though: I’m half Colombian and half Greek, I was born in France, and moved to the States when I was about 7. That’s the setup. I lived in Atlanta, Georgia most of my life, so when the time came to go to college, I went to Georgia Tech, and went from a computer engineering major to a computer science major when I realized computer engineering was interesting to me whereas CS was exciting to me. After graduating (actually, a little before), I joined an education company called OpenStudy that aimed to build global study groups around common subjects. We built something that was a hybrid of twitter, Stack Exchange, and real-time chat, and ended up with a pretty fun community of folks of all ages looking to teach and learn. When that didn’t ultimately take off, I joined Elemica, a company that helps the rubber, tire, and process industries automate their supply chains by facilitating interactions and decisions between buyers and suppliers (and other entities in their supply chains). 3 months ago, I joined the Keep project!
L: Could you tell us a little bit about your philosophy on decentralization?
A: I think the best way to describe it is, “it’s early days yet”. Or alternatively, “wait and see”. Decentralization (at least as it’s presented in the world of cryptocurrencies, public blockchains, and their ilk) is such a new phenomenon that I can’t claim to understand what the full impact will be. I can’t even really try to predict where we’ll be in 6 months. I think there are some exciting opportunities to rethink the way certain aspects of our lives work — I’m particularly excited about the concepts of decentralized governance and seeing what happens when a multinational business cooperative can be formed by a gaggle of people in a handful of countries by firing up a smart contract.
On the other hand, I think there’s a lot of naive idealism, too. Also, as with any grand and nonspecific idea, a lot of people can twist the concept of decentralization to explain the way they think the world should be (and try to get it there). If there’s anything I feel I can glean from watching computers go from boxes under our desks to screen-squares on our wrists, it’s that even when some individuals make predictions that turn out to be prescient, the collective crowd can rarely grasp what the 10- and 20-year impact of big technology shifts will be. I think all we can do is watch, try to contribute to the pieces we think are most important, and try to make course corrections when it looks like the technology is evolving in harmful ways.
L: You are relatively new to the crypto space, but you’ve been building software for over ten years with companies and for open source projects. What do you think the most striking difference is about building a blockchain project versus more traditional (non-decentralized) software?
A: Keeping up with the knowledge. When you’re in the development world, it’s normal for technology to be moving at the speed of light around you. But if you’re building a long-term project, you usually make some choices on the current technologies and then focus on building your product with those technologies. You keep an eye out on new stuff, but you can usually safely ignore it until something big needs to be built. In the world of cryptocurrencies, nothing is really stable enough that you can do this. You have to keep a constant eye on what’s going on, and stay alert for anything that could affect your current game plan. There’s literally new work and research coming out every week around various pieces of the core infrastructure.
L: What are you reading these days that keeps you informed and excited about the space?
A: I’m taking a “listen to others” approach right now haha. There’s enough reading thrown around just in chats and through my usual channels (Twitter, Hacker News) that it’s hard to keep up. I trust the folks around me to share important and interesting stuff, and that lets me focus on building out our team and our technology. I do keep an eye on a few subreddits, currently around Ethereum, when I have spare moments.
L: What made you decide to work on a blockchain project and especially Keep?
A: “Especially Keep” is really the crux. It was really two pieces: first, I’ve known Matt and Corbin for a long time, and second, public chains were always a bit eye-rolly for me precisely because privacy still seemed a largely unsolved problem. I think Matt, Corbin and I had all just been waiting on something that had us all equally excited at the right moment so we could work together. We knew we had compatible approaches to development, projects, and building teams, so when Keep came into the picture, I was super-excited. Keep felt like a solution to a very real, very core problem that would exist no matter how exactly public blockchains evolved. The added layers of prioritizing open source and building a remote team made it exactly the kind of opportunity I couldn’t turn down.
L: You’ve made some stellar additions to the Keep development team recently. Could you talk about what’s important to you when building a team?
A: I think there are a few moving parts to building any team: you want folks who are good, who can communicate effectively, and who can work together well. For a remote team, communication is an order of magnitude more important than for one that isn’t remote: written communication especially becomes the backbone of a team that doesn’t have 8 hours of face time a day. I usually end up selecting for folks who have great communication skills, a good eye for detail, and pride (but not ego!) in the quality of the work they put out.
L: We’re a completely distributed team, and you do an amazing job of keeping everyone connected. What strategies do you employ when facing the task of keeping everyone aligned on shared goals?
A: My goal is to be out of people’s way as much as possible so they can get awesome work done, while still working to solve the right problems. To that end, my mantra is: share everything and share it early. If you have a question, ask it early. If you have ideas, suggest them early. If you have code you’ve started writing, open a pull request early. If you have documentation you want to write, open a pull request early. Creating opportunities for iteration, ideation, and collaboration is a key piece of making a remote team operate successfully, in my experience. When everyone is working in different places, it’s super easy to go into a silo and tune everything out and churn out hundreds of lines of code. Sometimes that’s a great thing, but sometimes you emerge to find you’ve solved a problem that isn’t quite the right problem, and much of your time has gone to waste. To avoid that, you have to consciously create the opportunities for discussion.
L: We have a goal of building a strong community of developers and keeping our project open source. How do you feel about engaging with a wider community as we’re building the Keep Network?
A: That’s probably the thing I’m most excited about. Right now we’re in this pre-stage where we’re getting the broad strokes of the architecture written down and building out our initial code. That’s really important and really useful, and we’re making decisions while doing this that will have some long-term impacts. But my heart has always been with users: I like to see what people do when they get their hands on the thing we’re building. Engaging with the community is what Keep is all about, because we’re not building a single solution to a single problem. We’re building a key piece of the blockchain infrastructure that can be used to build many solutions to many problems.
L: How do you envision working with people who are building projects using Keep?
A: Fundamentally, I envision us working with a community of developers who are engaging with us as stewards of this core technology in their system. We’ve gone out of our way to figure out how we can sustain the project long-term, so that developers who are building something to last can use the Keep network with confidence, but they also need to see that their ideas and opinions matter (even if they’re not always the only factor). The code will be open source, and that means everything that comes with it: third-party contributors, transparency, the works. There’s always a careful balance you have to strike in community stewardship, between navigating the vision that you have for something and managing the competing visions that your users and contributors have. Our goal will be to have a continuous and open dialogue about how we are keeping those visions aligned. Beyond that, though, our goal will be to keep our community respectful. We want to build a community we ourselves would want to be a part of; indeed, I think we’re succeeding as long as I savor looking at what our community has to say today.
L: What are your favorite tools when working and coding?
A: Flowdock is our team chat tool. While it has its flaws, I have yet to find a tool that more successfully integrates data from disparate sources like GitHub, email, blog posts, etc, into a single place that can facilitate real-time discussions. Flowdock lets us have team chat that’s easy to refer back to when the results of that chat are actionable.
GitHub is our tool for managing code and documentation. In addition to being a stellar tool for working on our team, it’s going to give us a clean transition to operating as an open source project. The goal is to run the project from the start as we expect to when we open it up to the community.
I’m a long-time user of vim, but I’ve been toying with Visual Studio Code for our Go work recently. Historically I’ve changed editors once every year or two, with vim as a mainstay/fallback. 6 months ago I was using Sublime Text regularly. I try not to be too religious in my tooling, and I also try to use the minimum tooling I can get away with. I’m not the person who’s going to have 153 plugins and 67 customizations on each one. I try to use defaults as much as possible, because I consider it very important to be able to have a common vocabulary with others.
L: Anything else you’d like to add?
A: Just that I can’t wait to see what people come up with once Keep is a tool in their toolbox. We’ve already had some truly cool ideas mentioned in Slack, and I’m sure there are many more out there that haven’t been mentioned (or thought of!) yet. For me, there’s going to be nothing more exciting than seeing something built on top of what we’re putting together.
Learn More
For more information about the Keep Network:
- Join us on Reddit.
- Check out our whitepaper.
- Read our business primer.
- Subscribe for email updates.
- Follow us on Twitter.
- Join our Slack.
- Join our Telegram
For more information about Antonio Salazar Cardozo:
