Patrick Woods: All right.
Sam, thank you so much for coming on the show today.
Maybe we could start out by just hearing a little bit about who you are, what you're
working on and how you got into the wonderful world of
developers and communities.
Sam Ramji: Thank you very much for having me.
It's a privilege.
Who I am, I'm Sam Ramji.
What I'm working on is a bunch of things.
I'm the Chief Strategy Officer at DataStax, which
is a Apache Cassandra commercial
Also, working on Data on
I'm extremely curious about data meshes
and generally where the world's going over the next 10 years as we become
more and more of a data driven apps kind of
world, rather than app driven data.
So how did I end up in the wild world of developers?
Well, I started out as one when I was nine.
So in 1980 I started programming and that was pretty cool.
And it was kind of by me and others who did it at the time, we took it so much
We never thought of it as a job.
I ended up kind of being the unofficial TA for the AP computer science class in high
school, which again, it was the '80s so it was Pascal.
And I ended up going to UC San Diego pre-medical because,
again, like most of us didn't think of software as an industry
or a job or something that you could go into.
But then when I came through school I was like, okay, I want to build educational
So you could either be a product manager or you could be a
developer and I was like, well, I'm going to go be a developer.
So I spent several years engineering.
I love C++. Don't get me started on Java or C++ versus Java.
I'm still sad about how that worked out.
And then I worked for developer platform
I worked for BEA, the Java company.
I worked for Microsoft for several years.
Worked for Apogee, which was the API company.
We took that public in 2015.
Worked for Cloud Foundry, which is a developer
platform in open source, it runs on multiple clouds.
Then I worked at Google as the Head of Project Management for compute and
So I was VP of PM at Google from 2016 to
2018 working on Kubernetes and on Kubernetes-based
devops and then I tried to apply that to my last
job at Autodesk where I ran the cloud platform team.
It was about 1,100 engineers in I
think about 40 locations, a dozen countries supporting
Autodesk's need to become a data company.
And so, all that stuff has kind of lead me in my curiosity to
building open cloud hybrid data platforms that
are good for SREs and operators and that are good
Patrick: Fascinating story there.
You mentioned data driven apps versus app driven data.
Patrick: Could you unpack that a little bit?
Sam: Yeah. So we tend to work right now in a world of application driven data
or app driven data.
So where is the data?
It's stored where the app want it.
Where does the app want it?
Well, it could be on your device or it could be
in a microservice.
Well, what are they storing the data in the microservice in?
Well, who knows, it could be in MySQL, it could be Cassandra, it could be Mongo.
Okay. If you're not the app development team and you
want that data for something else, how do you get at it?
Well, that's an afterthought, right?
Because the whole focus of our world is application velocity.
Get the app, ship faster, get them iterated faster, get them updated faster,
keep the developers happy for sure.
Keep that moving fast.
As a result, it's pretty hard to get the data out.
So you end up with, how am I going to migrate the data?
How am I going to load it? How am I going to transform it?
Who needs it? Do I put it in a lake?
Do I put in a warehouse? Who knows, right?
Data driven apps, though, are the flip side and it's almost like the
difference between writing a recipe and following a recipe
for cooking, that's kind of how I grew up.
Procedural application development that emits data and
interacts with them, to something that's more like training a
How would you train a puppy, right?
So data driven apps are really ones that the behavior is
rising from a set of data that you have a set of algorithms that are
It's interpreting the data through human activity like
you've put labels, right, you've got data pipelines that tell you what this data means.
Like this is a giraffe and that is a tree, right?
How do you distinguish that so that the machine can learn?
Those machines that learn also have learning errors, we call it
drift or skew.
So it's quite a difference, more of an organic kind of model of thinking about
what is an app in a data driven apps world,
it's almost emergent.
Not precisely so but something like that,
versus what is app driven data, which is what's more predictable
I know what it's supposed to do, I know who it's supposed to serve and
I'm going to iterate that.
Patrick: Love the metaphor of recipe versus training a puppy.
Sam: It's a useful one, right?
It's very hard for people to move from their excellent
skills at application driven data, right, and
procedural programming over to this strange new
world where it seems like Non-Euclidean geometry, up is
down and down is up, what's happening?
So there's a little bit of a frame of reference.
One of the fascinating things that's happening is that the two are starting to meet
and people want a little bit of AI or ML, whatever you want
to call it, pattern recognition that's changing dynamically in their app.
A really simple version of this would be how awesome is it
that you have autocomplete in Google Search, and you don't
just have one suggestion, you've got a range of suggestions.
That's pretty cool data driven app
behavior showing up in an app
environment. Makes you smarter.
It learns as trends change, lots of different people are asking these questions
and you can actually watch Google learning through
And you can think of it, and I think this is
powerful, you can think of it as a UI over Google's knowledge graph.
So there's a way of starting to bring these two worlds together, right, and you start to
see some of the interesting things about how you get different types of developers
to work together, understand each other.
And how you get these sort of evolving systems to do something really
cool for users.
Patrick: So I'm curious about your perspective on developers,
how that's evolved over time about what they need, how to
empower them, taking into account the various roles
you've had from the age of nine, learning to program
Describe that arc of your understanding of the developer over
Sam: So funny.
I think it's partly a historical map and
then partly it's just a lifecycle that anybody would go through,
I think the first fascination for me
is, oh my gosh, I can get this thing to do exactly what I tell it to do.
I can use some of my knowledge of logic, maybe a little
bit of math and it can do really cool things for me.
How amazing. I think when you're a kid, right, you are
at the mercy of so many other people, right?
Where are you the master of a universe?
It's really important to have your own sandbox that you can build in.
So I think that first step is like, oh my gosh, look at this, I built this thing in my
Then once you get tired of building things in the sandbox you still want to build things
but you want them to connect, right, to the real world or however you
define real, right?
It's some domain of care that you have.
So how do I get that afferent behavior?
How do I get outcomes from what I did in my sandbox?
And I think the much later stages are like and how do I get that
thing to be a full loop, right?
How do I get the real world to then come back and inform the next thing
How do I keep iterating at that?
Kind of scaling up over time.
I think one of the things about being a developer is always curious,
Right, if you think about the persona.
At Microsoft they used to say, "We hire insecure overachievers."
I guess another way of talking about a developer
You're just trying to do more, you're trying to change the world.
You've got some crazy idea you want to see if it works, and you'll feel better
about the idea if it does work and if other people think it's cool, too.
So there's a sense of that underlying, I think, childlike curiosity that
makes life as a developer so fun and satisfying.
You are paid to learn and you can keep learning it
vertically, you can learn at bigger and bigger scales, become a principal engineer,
work on architecture or horizontally just learn more things.
Like hey, maybe you started out in ray tracing and now you're super interested
in database workload scheduling algorithms.
Cool, there's plenty of room to grow as a developer, that's why it's such an
amazing job and such an amazing community of people and just an amazing
Patrick: So thinking about the role of communities
or community as a concept in the context of that development,
that progression, what's been your experience in the
overlap between developer communities and the developer's
themselves and maybe the companies that participate
in those ecosystems as well?
Sam: Yeah. It's like are you looking at the parts, are you able to sum them
back into a whole?
How do how they connect?
Then one of the interesting sum of the parts and the wholes is can you
connect your go to market and how you think about measuring success
as a company with your go to community?
Can you think about those two things equally?
Are they symmetric?
How do you think about the ratios of how you expect
outcomes to be produced?
How do the two time sequence each other?
Does a healthy community tend to produce a healthy business?
Can you have a healthy business without being preceded by a healthy community?
Can you bootstrap it later?
I really admire companies that are built out of people who
fundamentally understand how these things work.
Often those companies and people who fundamentally understand how they work
don't have the science to write it down.
It's almost an embodied knowledge.
A bit about riding the bike versus being able to
write out all the physics of why the bike works and how it could
So we end up with really, really great
companies being repeatably produced by people who really
understand developers and how they constitute your business.
And then we have a bunch of other folks who are like hey, prove this thing about
No, explain the technique.
No, measure it. Don't tell me that you just need five more
Explain to me in dollars and cents how this stuff works.
You see these conflicts often at change of control, you get a new
CEO or maybe you've got a new strategy in a company
where you've got a very sales focused culture.
And the balance of power is always in people who can
measure their activities and have a good story about how those
correlate with results.
And one of the big gaps for the go to community arms of even
great companies is the ability to measure what they're
doing versus the outcomes.
So I think balancing this fundamental
sense of what it means to go to market with not just an
embodied knowledge, but a scientific knowledge of how to go to
community is super important.
I learned a lot about this at Microsoft where they had built a
company really on developer experience fundamentally.
And when you look at how companies behave and how people
care about things, they tend to care about what gets you paid.
So at Microsoft there was a balanced scorecard, it wasn't just revenue.
One of the huge elements on the Microsoft scorecard was dev
tracker, which is a combination of developer
satisfaction, NPS, a few other components
bundled up into one number that
every executive at the company could look at and know it was going to change the
So it turns something that is often fuzzy
and feel oriented into something that even the folks who
want to be able to manage the company on a spreadsheet can see it and say, is that
number going up or not?
And then you can start to balance that conversation instead of saying, hey, I need five
more community leads.
You could say, in a
population of this size, right, we've got Brazil and we need
to increase our dev tracker score by four points
That really means this many more human beings
applying themselves to these roles using our technology.
Typically, we see that we can have a community lead per
let's say 100,000 people in the population.
We want to reach another 500,000 people, I need five leads.
Those kinds of conversations move into equal footing with
everybody else who's trying to get a piece of company capital, whether it's marketing
or sales or product or engineering.
Patrick: That's amazing.
So at Microsoft, with dev tracker in
particular, was the dev tracker aligned in the scorecard
across all executives or from certain business units, or what did that look
Sam: That's the beauty, every single executive.
And when you look at the intentionality of that structure, at the time
that I was there, we had about 80,000 employees.
We're around 60 billion in revenue, and the
top 120 people in the company, people with the title Corporate
Vice President, right.
These are the folks who are alternately
running product units, running really big functional
organizations like marketing or running regional sales
We had a Corporate Vice President
for Africa, Corporate Vice President for the Middle East.
So large regions, all of them were uniformly
compensated on this balanced scorecard.
Which I think was Microsoft's breakthrough innovation
in corporate governance to be able to balance these two
sides of what makes developers incredibly
engaged and happy with what you're doing, and how does that turn
into a sustainable business.
Patrick: Yeah. This is getting in the weeds a little bit, I guess.
But I am curious about the inputs into dev tracker, how are
those inputs validated in the connectivity between what was
in dev tracker to what actually moved the needle on the business side of things?
Sam: That's a great question, because that was what enabled me to do the work that I was doing
in open source at Microsoft.
Change at any big company isn't going to happen because you think,
"Oh, my gosh, I got this great idea.
Everybody's going to be in love with it."
It happens because you can show the
connection between this new idea and it's differentiated ability
to hit the metrics that you've already been told to hit as a company.
So inside dev tracker, it was a pretty neat and
substantial cross company process.
But it was repeatable, which was why it was useful as a tracker
As I mentioned, it was a combination of developer set so it's like a customer
So we ran surveys, NPS or net promoter score, so
that's also bundled in the survey.
And then a set of instruments showed us how many people are
using this technology versus that technology in the market.
So we would buy data from IDC, we'd buy data from Evans Data
And then with all third-party
information, you always have to triangulate it so you have your own view of
it that you understand and believe in.
Because if anybody starts to question the reality or the metric, then the whole thing
By the time I got to Microsoft, this was well
understood, I learned it there and it was generally accepted.
And one of the things that happens there when it's generally accepted is it's
And standardized things make you smart because now we
don't have to have the whole conversation about how do we know, right,
the epidemic argument.
We can just say, how's it going?
And all of a sudden our conversations can get super efficient.
So we also did a bunch of in depth interviews in dev tracker, this is
where my open source story comes in.
And to use the example of Brazil, which was a live example,
we found that a lot of developers had particular
feelings about Microsoft and about non Microsoft
One of the biggest
opportunities that they surfaced was, hey, we really, really
This is just an amazingly strong PHP company.
PHP runs really badly on Windows and it runs amazing on
And so, when we choose PHP, we put Linux with it.
So then that starts to give you the depth of view from
And says, hey, what if we
made that work really well?
What if PHP on Windows was amazing?
And then could we take that back into Brazil and communicate with
developers there and say, PHP on Windows, who knew?
How do we help you try this out?
And does that make a difference to our business?
Can that move share?
Because now when you pull PHP is there a chance to pull Windows instead of
So these are the kinds of things that you can pack
into a really disciplined dev tracker, there should always be
room in that instrument for some novel
strategic questions that could offer some kind of cool
Patrick: Love that. So our audience
contains many early stage founders of
developers tools companies, API platforms, open source, open
I'm wondering how you would translate
this approach that worked at Microsoft on a global scale down to
a seed stage or a series a company.
What advice would you give them for creating something similar that's stage
appropriate, but also equally as powerful for their purposes?
Sam: Sure. I think a great question is always who is
using my product that I don't know about?
When we think about where web API's came from as an industry,
I spent too much time on that in Apogee and I had to ask
myself the question historically like, why is this happening?
Who's using it?
We found that the best signal that somebody that you didn't
know was using your stuff was that they were using a web scraper, and they were
turning your website into an API.
That's super interesting, right?
You can either shut that down, block the IP
address or you could be like, "Oh, my gosh, somebody is using my
service to do something I didn't anticipate."
This is a signal this might be an
So it's an orientation, right, as a
management team to look for these novel uses outside
of what you thought.
Because in my experience, and I'm in my sixth
startup now, people never use your software for what you thought they
use it for.
And when they start using it for this
other thing enough, that's actually the shape of the business that you're meant to be in.
So think about developers,
especially ones that you haven't heard of, as opportunities for you to get a
new view into your future.
Now, these days you've got companies that are assuming that API's are going to be
part of what they offer their customers.
So most companies that are providing a service have some level
of customization or interaction that they expect developers need to work with.
So in those cases it's more an extreme version of what
I was describing before, don't just kind of watch what they're doing, but
actively serve them.
Ask what are their use cases, make sure that you're talking with
them in depth.
And this is where you can actually use anecdata
at the beginning.
You could say, okay, if I have 20 pieces of
anecdata, somehow that's a data corpus.
Do I trust myself to have a field to work on developer product?
Have I work with other people who've done this before?
The final piece would be developers are your
And in that, you're going to really tackle this
as the whole structure of your business.
You think of the developer is the buyer and the user, you apply a lot of
your fundamental marketing and product management techniques that you already
have but looking at the developer.
In all of these cases, I think the great metric is
Now, depending on your product,
you might look at daily active, you might look at weekly active, you might
look at monthly active.
Define those things the same way you do as our service.
You shouldn't look at just the interactions the developer has with your UI.
UI, because mostly a developer would prefer not to use a
So that might be a part of your signal.
But a database or an application tier that hasn't been
modified in several months, it's much more important that it's serving
So how do you look at that other
component, right? Is it your apps?
Is it the interactions?
What is the interaction that you want people to have with your
That's a super interesting thing to measure no
matter who your user is.
If developers are also your user, you want to measure your active
developers over time.
So that you understand just like a sales channel, are they converting
appropriately from registration to use?
Is their level of use deepening?
Make sure that as you do this, you've got enough signal
in there that you can disambiguate developers from each other,
that you can look at the movement of developers across projects, that you can
look developers within orgs, that you can look how orgs
A great way to lose all this information is to
conflate it either by not knowing the difference between several
different logins from one developer with different unique names.
Or by having a identity model that is too
naive and doesn't anticipate the sort of
multiply inherited nature of a human being, right.
You can have multiple classes, don't get me going on C++.
Or the change over time of people,
projects and companies.
Patrick: That's fantastic and immensely applicable.
We shipped in API with essentially version point one of
Orbit and have learned an immense amount from our early
users and how they're using in some cases, not
quite abusing it, but are using it in creative ways.
But it's such an immense surface area for learning for us
as we think about the product.
Sam: Right. So treating it as such means instrumenting it
because pretty soon you're going to be looking for the outliers
because there'll be more interesting than the core signal.
Can you find the outliers?
And can you see this as it scales?
So if you don't do this, if you don't have that orientation
towards, hey, let's have telemetry, let's treat this as signal.
Then you're going to be back in the world I described where people
kind of know how it ought to be, but they can't prove it, right?
They've gotten the equal, but they don't have the quants.
And in any coherent managed corporation that grows over time,
the quants are always going to have the upper hand because you
have to decide where to put your money, and who to hire.
All right. As the CEO of Orbit you know that, right?
Patrick: Yeah. That's right.
Sam: How managing capital is the CEO's one core
job that nobody else can really do.
They can never step away from that.
So the ability for the CEO to make the good decision,
hire one person here versus hire one person there, that's got to
be backed by data.
So if you start out by not collecting the data, you
won't have the signal.
And you probably won't have the right culture because you'll end
up with people in your developer community team who all get along
super well and they use a lot of jargon, but they can't do the
entrepreneurship move of explaining to other people in a compelling
way, right, with both the poetry and the numbers about
why this is a good idea.
Patrick: So you tweeted something recently that I want to read.
So I'm going to make you listen to a tweet that you wrote, but
then have a question about it.
Sam: Is this going to be like celebrity mean tweets? I don't think I can handle that.
Patrick: No, this one was great.
So you said, "A good tool should standardize work.
If it standardizes that work in the right way, it should create more
competency for the user.
Systems of tools should teach us how to collaborate.
If they define collaboration in the right way, they should create more harmony for
So I'd love to get your perspective on
how the most effective tools standardized work and they teach us about
Sam: Yeah. The creation of a good tool is a lot of
cutting out of negative space, right?
The fact that hammer is a hammer and it's not a drill.
Somebody put a lot of effort into thinking through, right, how does this fit the
hand? What does it do?
I'm sure we could all design a better hammer, but we have the hammers we
But a hammer is a pretty dumb tool.
It gives us a little bit information like when you hit your thumb, don't do that.
But it doesn't tell you that much about how to do the work.
So as we think about smarter and smarter tools, and we have so many
these in technology, they should by design take a bunch of
choices away from you.
Because it turns out chaos, that doesn't help
You want to eliminate a whole bunch of non meaningful choices,
so that we can spend our limited heartbeats quickly doing things that matter.
Design is a lot of that removal of
choices. They say design is done, not when you can add nothing more,
but when you can remove nothing more.
So I think that's a lot of the good tool design.
Building more competency for the user, I think ends up being
that same thing iterated again and again.
The more that I use, let's say Google Docs, the more that I
can see other people interacting in.
I can see when I'm stopping on something, I know when
I'm creating more space for other people to participate.
I know if I'm using suggestions versus editing mode versus
There's a surface area constrained
enough to be useful.
But it also teaches me a bit over time, how to become
more competent not just as a writer but as a writer of shared collaborative
documents, there's bits of feedback in their.
Twitter in a way helps you become better at
using it because you have feedback right in the tool, right?
You have your likes and your retweets.
So at least for you as a situated being, you
can grow competency at that thing, right?
Hopefully use it for good, not for evil.
But that's an ethical question, not an aesthetic one.
So that's a core piece there.
When I look at companies like Atlassian,
surprisingly, if you look at SAP, if you look at Microsoft
Office, you end up seeing a whole bunch of design
choices about how work autoflow.
Some really great tools like Concourse, if you think
about that as a visual code pipeline tool,
it takes a huge amount of choices of how you might think
about the problem of shared collaborative code
development, and what is good state versus bad state.
It takes that right out.
And it gives you a visualization of what is the state of work
that maybe previously you had on whiteboards.
Or previously, maybe only the release engineer was able to construct in their own mind.
And now we can all see the shared state of that
thing. That's amazing.
So when we see that something goes from green to red, we can all
step in and we can create a practice around that and say,
okay, what was the root cause of this going red, let's make sure that doesn't
And it creates space for particular conversation.
There's probably even more higher competency ways to come after it like we have
in sort of the DevOps or the SRE manifesto of
sort of blame the process, not the people know.
No grumpy humans, let's do this as a blameless post mortem.
Whatever that human structure we put around in it, it's all enabled
or disabled by can you see the build process?
Can you see the pipeline? So CircleCi, Concourse,
I think a lot of the DevOps tooling that we're seeing or some of the shared observability tools.
Note that I said shared observability tools,
because they're trying to standardize work for a number of
people to all come together around, maybe a production
down or a production downgrade
incident, and that requires collaboration.
So it pulls us in no particular shape.
Rather than us going crazy pulling a whole bunch of log files,
flinging around, imagine if you would the farthest pace from the
happy center, that would be a perfect tooling experience, you'd be on tattooing.
You'd be drowning in spreadsheets, you'd be arguing with graphs, it would
all be Excel and you'd be using an ancient version of
Windows that made it really hard to look at the same thing with no
That would be bad.
That would teach you risky, bad ways to work.
But a good modern tool in DevOps gives you shared
transparency of the problem from a very
opinionated point of view.
And I think that teaches us how to have more harmony because
we have already agreed on a problem definition and a
visualization mechanism, and now we can just get after the getting.
A little bit like what dev tracker did for Microsoft, it helped
And it encouraged forms of
collaboration that would move that number and encouraged
Even things that they hadn't designed in, but
we could make a common argument that said we should embrace open source on
Windows as a marketing campaign, as a technology
because we have the shared outcome of dev tracker and we need to move that score.
Don't trust us forever, let's run this for a year and see if it moves.
Patrick: It does seem like for tools to fully self actualize,
they have to have an opinion about the best or the
Sam: It's incredibly generous to be opinionated
in a tool.
Because without opinionation, you
have a tremendous amount of cognitive load.
So let's imagine the only tool you could possibly have for the rest
of the operation of your business is Google Sheets.
Well, that's great. It's almost unconstrained.
It's almost unbounded, right?
You can call out to other languages, you can create a Turing
complete model of your business.
But what did you decide?
What did you choose was in, what was out?
That's a team decision for every single team that solves a
problem, and maybe for the same human multiple times a week.
What do I do? So to start to standardize that work,
says, I'm going to do the cognitive load management for you
and I'm going to hand you something as simple as a pipeline.
Everybody can visual left to right pipeline.
Is it a sales pipeline, is it a production pipeline, is it a supply
I don't know.
But now I can see the flow of things over time, and there's a set of stages that have
And so, now, I'm assuming this is competent.
And I don't have an MBA in this stuff, but I've got my one A.
You got educated on how the work ought to be done because you can see this
So that I think is kindness.
It's also kindness because it's competing in the marketplace.
If you don't like the opinion that was rendered by this firm,
Pick your own, right, you have agency.
But manifesting your point of view in
specific design, taking a whole bunch of different ways to solve the problem
off the table and just giving people a good view
of how you think all that got to get done, that's really helpful.
Patrick: I love the view of choices, kindness.
And I'd like to shift gears a little bit in here a little bit more about
kindness for you, and how kindness as a
philosophy has been a big part of how you carry yourself
to the world.
Sam: Yeah. It's something that I think all of us have, an
unbounded ability to get better at, there's no perfect score.
And I think, for myself, every time I look back a few years
at any given piece of my own history, any interactions I've had,
I think the ones that I regret were like moments
where I think I could have been more kind.
If I just had to look at more of my presence, maybe a little bit
less of my ego, a little bit more breath, there's almost always a way to
go back and do it better.
And I do think the directed path is kindness.
I think kindness, first of all, enables the kind of shared
trust that is the emotional
operating system for collaboration.
I get really excited about a particular form of collaboration open source,
but collaboration itself requires us to trust
each other, usually with pretty unformed ideas.
We're all going to mutually step into some piece of incompetence.
And if we feel like when we're showing up as incompetent, when we're
blundering through our words, when we've got the brandest
newest idea, maybe in a domain we don't understand well, are we going to get
laughed at, right?
Or are we going to get smiled at?
And if you know folks are going to smile and help you move the idea forward
from being a terrible idea being a good idea, then
magic can happen.
So for me, there's this spiritual
lineage of kindness that I admire.
And I think when we look at great leaders in history, at least the ones
I pay attention to, typically reputed
for kindness and the outcomes that they produce.
But just practiced in our daily life, if we can
give each other just a little bit more grace, step away from our own
reactions, then we might even end up being kind to
And if we suffer less, we'll probably visit
less suffering on others.
And that seems like the kind of world I'd like to live in.
There's a link to economics here as well, which is, the positive some
games that I like to play that I think most people like to play.
Where it's not like a sports game of nonzero sum, where you're just going to
step onto a field and one team is going to win and one team is going to
lose and that's the end of it.
But to be able to say
the more of us who play this particular game like love or an
open source project or good stewardship of the earth, the
more people who play it, actually, there's no upper limit to how
awesome that game can be.
Unlike a zero sum game.
There's also negative sum games, which we don't like
very much like pollution and global warming and the more people who played the
worst thing is good.
So if we can find the shape of positive sum games, I think
all of those have an immediate link to kindness.
Because if you can start to think about, what is kindness at scale?
It'd be really good outcomes for people's own sake times
thousands, times hundreds of thousands, times millions.
Those start to look like markets in a way, right, those might be enabled
by platforms of a particular kind or a style
But you can end up with lots and lots of people in a
positive sum game.
And that seems like a tremendous source
of power and good outcomes for all of us.
So very philosophical, but I'm turning 50 this year, so hopefully you'll
forgive me, my bent towards thinking about the world and our
place in it.
Patrick: All these conversations, we typically start fairly
technical and end fairly liberal arts, so it's not
uncommon for the arc of the conversation.
Sam: That's such an interesting comment.
I think, what makes me really happy is that our
industry is starting to balance its affection
for science and for liberal arts.
And that to me is a great sign, not just in terms of
inclusiveness and bringing people from many walks of life into this
industry that I've spent my whole life in that's provided me with
nonstop ability to satisfy curiosity and a good living to
support my family.
But also, that we're going to come
up with better solutions, more interesting shapes of
worlds defined by software that are driven
by people who can marry technology and the liberal
arts as Steve Jobs said.
Patrick: One thing that we think a lot about at Orbit and are working towards
all the time is changing the culture and the tooling
around this space.
For me, it's an exercise in the sort of art and science of
community and company building and strategy.
And ensuring that the tools we build are consistent with
the values we hold and the culture we want to create.
So I think it's consistent with what you're describing there about the general
shift in the industry.
Sam: I think both at the top level, Orbit.love is
the URL, right?
That's a really bold choice, right?
It's not an obvious one, and there's a lot of risk that you've chosen to
take on the chin and write directly into your
That's pretty awesome.
Below, the design that you put into Orbit,
both as the open source model and as the tool that
automates interactions with it is really
It puts the focus on the human being
and doesn't reduce human beings into leads.
Sam: And I think that is just fantastic that it's an Orbit and it's not a
funnel to a pipe.
I mean, bless selling bless sales
process with bless sales tools, those have to run the
way that they do.
If we come at the world from our point of view, our
learn history as developers, literally every developer is a
person unique and curious in particular ways and involved
in different things.
And that being the basis of
how Orbit works, I think is inspiring.
And effectively it's an opinionated point of view, and takes a
lot of ways of looking at the problem off the table and
actually implements a certain set of ethics and aesthetics
right into the core of it.
And I'm inspired by it.
And I hope that that's something that that keeps self
projecting, self propelling and self correcting.
Because a tool that's that powerful could end up getting subordinated
to serve other purposes, right.
Never cross that uncanny valley, right.
But allow the culture to keep pulling you into
always focusing on developer love. Right.
What is it that this human being is trying to get done and how can we help them?
Patrick: Yeah, yeah.
I appreciate you saying that, that's right on with kind of our vision
for things and that the love.TLD was a deliberate
signaling choice and it's worked.
But it's been fun as almost a verbal business card, like shoot me an email
And then people are like, what, dot love, what does that mean?
And then it's a narrative look to describe our philosophy
and our worldview. So it's been fun.
Sam: A bold choice and a tough one.
Again, there's so much, I think, honor and
generosity in being opinionated.
Because people can choose not to share your opinion and that's
But if you don't let them know what your opinion is, and it's
kind of like an ongoing hoodwink, right, they already know what you stand for.
You can agree with anything.
So if you're just like, hey, here's what I do and here's
what we're about, right?
We're available to meet.
Then the people who really do get excited by that show up
and form your core community and nobody's confused.
Patrick: So speaking of love, the show is called Developer Love.
We talk about love a lot, obviously.
So one question I ask every guest is, what's one thing you're loving
Sam: Well, I guess I'll pick three,
if that's all right.
This is not going to be a super technical answer, but there
may be some technology in it.
I love watching my wife's progression into becoming a fine
artist and seeing how that's been accelerated by Zoom, of all
things, because of the kinds of classes and experts that are
So it's some technical enablement there.
I love seeing my daughter starting to get fascinated in data science.
She's graduating from UC Berkeley with a degree in environmental
sciences in just a few months.
And as she looks at this, she looks at the tools of
R and Python and how to interpret data and visualize it to
help people move forward to take better care of the environment.
So it's fascinating to see technology written underneath there at that very
And I love
what my son's doing.
He's a PhD student at UC San
Diego, in nano engineering and try to
solve very, very low level problems of emulating
biological filtering of materials and being able to
reproduce that in human made nano materials.
So a lot of that ends up dealing with
computational nano chemistry, right, your ability to simulate a
novel material 50, 100, 1,000 times
in a virtual space before you actually go through all the
process of like, oh, we're going to photolithography and we're going to lay down
these nano sized holes.
And then we're going to grow nanotubes in them.
And then we're going to surround that with polymer.
It'd be nice, compared that it's got a pretty good chance of actually doing the right
thing before you reduce it to practice and try to make it something in the real
So those technologies at the interface of all of these kinds of
Patrick: Well, Sam, you've been super generous with your time today.
What an amazing conversation.
If people want to learn more about you and what you're working on online, where would you
send them for more information?
Sam: That's a great question, you can come find me
@sramji at Twitter, take a look
at what we're doing at DataStax for sure.
There'll be, I think, a lot more interest in data on
Kubernetes in the near future.
That's a place that's just totally fascinating to me.
And then one more that I point out, which is
And there's a really amazingly cool community shaping up
It's inspired by Zhamak Dehghani,
who's a technology director at ThoughtWorks.
And she's put together a bunch of the things that she's been learning about data
architectures in the real world connecting the
application plane with the analytics plane, and a
community has kind of self generated on slack
about, 800, 900 people already talking about architecture
How the old way is not working.
What is a data mesh?
So those are the shapes of my thoughts these days.
I haven't been publishing on blogs for a long time, so
there's nothing novel there but I should get on it.
Patrick: Awesome. Sam, thank you so much for the time today.
Really appreciate it.
Sam: Thank you, Patrick. Great to talk with you.