- Giant companies like Facebook, Google, and Uber
have thousands of world-class engineers
and they invest hundreds of millions of dollars per year
into a very important thing: developer experience.
Why do you think they're able to build such good products?
Well, one of the reasons is they have people working
on tools that make developers super productive.
But if you're watching this
and you're not at one of those big companies,
what do you do?
Today, we're sitting down
with the co-founder of Trunk, Eli Schleifer.
He's one of the smartest people I ever got to work
with when I was just 23, starting my career at Microsoft.
And as luck would have it, many years later,
we recently led a Series A for his company
alongside Andreessen Horowitz.
So now I get to work with him again.
- It's why people like love early development.
It's like, "Oh, I'm alone.
I get a lot of stuff done. I can code away."
But as soon as you add two or three people to a team,
everything starts to slow down.
It's the Mythical Man-Month hits you.
And you're like, "I can't get stuff done
because I have to coordinate with a bunch of people."
But with good tooling,
you actually can get some of that time back.
And we think that there's a tremendous opportunity
to build like a Google engineer.
At Google, they've invested tremendously,
building this huge library of tools
that keep everyone on rails.
And the truth is like only really Google and maybe Facebook
have enough tooling in place to do that.
Everyone else is kind of scrapping along.
That's why we started Trunk.
We want to bring Google-quality developer experience
to everybody.
- If you're an engineering founder
or engineering manager of any kind,
you're going to want to watch this to the end
to see how you can get all the tools
Facebook and Google engineers take for granted.
Let's get started.
Now, picture this.
You're an engineer and you show up to your desk,
you sync to the newest code base
and you try to run things, but it's broken.
What's your next step?
Hit Slack and ask for help.
Multiply that out by dozens
of people hitting the same thing
and you just burned $10,000 worth
of developer time in a single day.
Multiply that out by all the times that happens
per year and that's a million dollars off your runway.
It sounds ridiculous
but it happens every day at most startups.
And that's why Trunk Actions is here to save you.
- We were just thinking there's a better way to do this.
Like the rules
for how to build your site
are already known to your repository.
So what if we could actually encode
that inside your site using Trunk Actions
and that's where we're going to demonstrate here right now.
So in our case, what we've done is created a file trigger
and the file trigger just specifies
that the documentation changes that happen
to my markdown files
in this one folder should trigger a particular action.
And that's going to basically show me
the Docusarus command I should run.
So it's as simple as going into our docs here
which are all up on our website.
And I can go into the intro file
and I want to change this particular entry.
And I'll do a quick change to this file and I save it.
When I'm saving that,
what actually is happening is in the background,
the Trunk Daemon is running, it's monitoring these changes,
firing off this custom action trigger,
and all it says is when one of these files ends,
create this little entry
inside my VS Code extension to let me know how
to run the Docusarus site.
So if you go right now to the Trunk extension,
you'll see we have this cute little Docusarus
link right here, but I click run action,
it's going to spin up that site
and I didn't have to look it up.
It's just going to do it for me
and I can quickly go to work
and make sure that what I did looks right inside the web.
And that's really what it is.
It's a simple, if this, then that
for your repository.
So if I want to make a change to this file,
then spin up this website.
You're going to get to work.
So you can see here, this thing spun up.
Now I can click on the website
and here's my changes, it's reflected.
But that was just as simple as clicking the button,
it spun up.
I didn't have to figure it out.
I didn't have to understand how the thing was run.
It just told me what to do.
And I think that's so important
to kind of have that helping hand
to keep you kind of in flow.
Everything we do at Trunk is
about keeping engineers in flow.
So you don't have to shift
between looking stuff up, bothering other engineers
for things, you should just keep doing your work
and stay productive.
- That's the surprising thing about developer experience,
just like an iPhone literally started as just a phone
and a web browser, and gradually became much more
than that in society because of the apps they've created,
Trunk Actions is surprisingly powerful
because it's a jumping off point for those tons
of uses teams or developers need to work together.
Take for instance, your package.JSON file,
your dependencies for your libraries and your project,
getting pulled in.
Millions of engineers every day have
to remember to do this manually,
which really adds up because sometimes,
you just don't know when you need to do it.
- So what we've done is we've actually wired this again
into our system for Trunk Actions.
So I changed the package.JSON file
and it's going to pick up the change.
It's then going to run a dry run of Yarn install
or NPM install to see if there is something to do.
And if there is, it's going to give a little pop up
to let me know, hey, you should run Yarn install.
So instead of me suffering through this,
it just tells me what I should do
to get things working again.
We actually had an engineer start at the company.
She was new to the company.
She was working along, really well,
working for months on end.
And then someone changes the package.JSON file
and after struggling with this thing
for half a day, she finally Slacks the team like,
"hey everybody, what's happening here?
I'm getting this weird error"
'cause it'll show up some random compilation issue
in type script.
Most engineers want to try to figure things
out for themselves.
But really it was just a case
of there's new dependency that was added,
you have to run Yard install or NPM install to fix that up.
In this case, she just didn't know to do that.
So had she had Trunk Actions,
she could have just kept working,
instead she lost half a day to this thing.
- Can you imagine developers all over the world
losing half a day to something like that,
just for no reason?
Like we said, that's a thousand dollars set on fire.
Trunk Actions works on most dependency managers
and they're adding new ones all the time, Yarn, NPM,
whatever you got.
- And then you'll get a little popup
inside the actions thing to tell you, Hey,
you need to run Yard install or NPM install,
then you're back to business.
And that is just like magic.
When this thing starts happening for you,
you're like, this is a better way to build code.
- Trunk Actions can be used
for almost any development change,
whether it's dependencies or even database schema changes.
It takes the guesswork out of developer teams.
And that's great for developer experience.
So you probably use Git, most people do,
but you might get annoyed once in a while
because you have a big merge and it's a conflict.
But when you're a small team, that's manageable.
It goes from manageable to totally nuts
if you have dozens of developers or even a dozen or more
and that's why Trunk has now made merge queues
the way all the best development teams do code merging,
available now for everyone.
Here's Eli again, showing us an example
of just a run of the mill, day to day,
problematic code merge,
the kind everyone hits sooner or later.
- Problem is that these two tests work independently.
But these changes actually are logically in conflict
if you land them together and this will create
what we generally call like a broken main,
where you've landed code that was individually okay,
but when combined together, is broken.
So in this case, we kind of playfully created
a Heisenberg test case.
So we'll take a look at the code quickly here.
In this case, we have added a negative test
to say that when someone is saying a particular input,
if the input is Heisenberg, it should say you're right.
And if the input is Walter,
it should say you're wrong.
That's a valid test.
You can see from the check that it passes
and the thing is all green.
So great, that engineer is ready to land that code.
We'll look at the other PR here,
the other pull request says add more allowed names.
So this is another engineer.
Let's say you, Garry, went in and said, you know what?
There should be additional names that are allowed
inside the system.
I'm going to say the allowed names list
now includes Heisenberg and Walter.
And I'm going to make sure
that the test checks against this new vector that I checked,
allowed names instead of a higher hard coding,
this word Heisenberg.
This is obviously a trivial example,
but this kind of stuff happens all the time.
As soon as you have more than one engineer working
on something,
you're going to have cases where logical conflicts can show up.
And when that happens,
kind of it's super dangerous, but what can happen is,
you'll land these things, they're going to land fine.
But then another engineer, a day from now,
two days from now, is going to try to put up a pull request
and the unit tests are going to be failing.
And the first thing they're going to think is, oh,
I broke something.
So they're going to go and try to figure it out.
And then it turns out it wasn't them that broke it,
it was because these two PRs landed
in conflict with each other and trying
to tease that apart is a giant waste of time.
It doesn't move your product ahead.
It doesn't keep you focused, doesn't help you at all.
It just is a way to burn time.
This is why you need a merge queue.
- Now let's look at how much better it is
when you do use a Trunk merge queue.
- I'm just going to quickly call out here,
we'll say Trunk queue.
So Trunk will listen to comments
on top of the pull requests.
When you say queue,
it's going to tell it to go and queue this pull request.
So I'm going to queue this one and the other one.
Now we know that these two pull requests are in conflict
with each other and the queue, the merge queue,
is going to protect the main from getting broken.
So I've queued both of these.
Now let's quickly switch
over to actually look at this in our merge queue UI.
In this case, these two pull requests are being tested.
Now the interesting thing to note is that they're actually
being tested collectively against each other.
So the first test, the first pull request here,
is going to actually pass because that one we know can land
because there's nothing in conflict with it.
But what we'll find out is
that this other pull request that basically was logically
in conflict with the pull request that landed before it,
is not, and it's going to fail out
and we are going to protect main and instead
of allowing this thing in and breaking everyone's
and ruining everyone's day,
we're going to protect main and keep it green.
So the main pull request that is going to be in conflict
will get kicked out of the queue
and the engineer can go sync up.
We'll see that Matt made a change to this particular file.
I need to go and update my code
and then I can requeue it and land it.
And we've just saved everyone else from all the hassle,
trying to figure out what went wrong.
You can see here, we just have the two results
for the two pull requests that I just landed.
Here is the green one that just landed,
that was pull request number eight.
Then you can see the pull request number seven was rejected.
If I click on that and try to understand what happened,
I can see it was submitted,
it was tested and it failed.
I click through back onto the workflow and I'll see
inside GitHub that this thing, well, failed to build
'cause it was logically broken.
So here's our test that it says
that the previous test was no longer passing
and we don't let this through.
So we protected main.
We keep everything green.
And we also gave quick insight into the engineer
to understand why was my pull request rejected?
I see this test failed.
It used to be green,
but now actually main has moved forward
since last time I ran CI.
- So that's a simple but common example
that happens on every dev team constantly.
If you're working with other engineers,
conflicts are a huge nightmare.
- If it happens once every month,
you just lost like half a day or a day of work.
And that's a tremendous waste of time.
And no one is happy to go home at the end
of the day, be like, know what's great at work today?
I figured out there was a logical conflict
that two pull requests landed together.
And then I sorted that whole thing out
and doing a git bisect, no one wants to do that.
People just want to like move things forward.
It's the thing that we hear so much from engineers.
The reason why I want to go work at a startup is
'cause I want to get stuff done.
'Cause at a larger organization,
when the tooling is not in place,
it's very hard to get things done.
You're just spending so much time kind of fighting uphill
against like all the other stuff that has
to happen to make software engineering work.
- Developer experience is how you can get untold hours
of time from your most expensive resource, engineers.
So what does it look like
to save yourself from the mythical man-month?
We just saw two really powerful examples
of saving many hours of developer time.
Just as a samurai must have the best sword,
so too, must your engineering team build
with the best developer experience
and that's what Trunk is for.
- So everything we're showing here today is available today
on the internet.
You can go and download it super quickly.
Just go to our homepage, Trunk.io, click on install,
and we'll give you a curl link to get started.
It's free for small teams,
any team up to 10 engineers in commercial products,
no problem free for you to get started.
Also always free for open source.
So any open source project out there, no matter how large,
always free for you guys as well.
- So that's it for this week.
Code is inheriting the earth
and helping people build better code faster
and helping engineers do their best work
is, I think, one of the most valuable things
a startup founder and engineer like Eli could be doing.
Thanks for watching all the way
to the end and I'll see you next week.