Helping To Build Cloudflare
This is the text I prepared for a talk at Speck&Tech in Trento, Italy. I thought it might make a good blog post. It originally appeared as a 6 part series on blog.cloudflare.com.
Part 1: How I came to work here
I’ve worked at Cloudflare for more than seven years. Cloudflare itself is more than eight years old. So, I’ve been there since it was a very small company. About twenty people in fact. All of those people (except one, me) worked from an office in San Francisco. I was the lone member of the London office.
Today there are 900 people working at Cloudflare spread across offices in San Francisco, Austin, Champaign IL, New York, Washington D.C., London, Munich, Singapore and Beijing. In London, my “one-person office” (which was my spare bedroom) is now almost 200 people and in a month, we’ll move into new space opposite Big Ben.
The numbers tell a story about enormous growth. But it’s growth that’s been very carefully managed. We could have grown much faster (in terms of people); we’ve certainly raised enough money to do so.
I ended up at Cloudflare because I gave a really good talk at a conference. Well, it’s a little more complex than that but that’s where it all started for me without me knowing it. Fifteen years ago, a guy called Paul Graham had started a conference at MIT in the US. At the time Paul Graham was known for being an expert LISP programmer and for having an idea about how to deal with email spam. It wasn’t until a year later than he started Y Combinator.
Paul invited me to give a talk at this MIT Spam Conference about an open source machine learning email filter program I had written. So, I guess the second reason I ended up at Cloudflare is that I wrote some code and open sourced it. That program is called POPFile and you can still download it today (if you’d like your email sorted intelligently).
I wrote POPFile because I had an itch to scratch. I was working at a startup in Silicon Valley and I was receiving too much email. I used Microsoft Outlook and I wanted my mail sorted into different categories and so I researched techniques for doing that and wrote my own program. The first version was in Visual Basic, the second in Perl.
So, I got to Cloudflare because of a personal itch, open source, public speaking and two languages that many people look down on and joke about. Be wary of doing that. Although languages do make a difference the skill of a programmer in their chosen language matters a lot.
Sharing
If there’s a lesson in there it’s… share with others. Share through open source, through giving talks, and through how you interact with others. The more you give the more people will appreciate you and the more opportunity you will have. There’s a great book about this called Give and Take by Adam Grant. We gave everyone at Cloudflare a copy of that book.
One of the people who saw me speak at MIT was Matthew Prince, Cloudflare’s CEO. Matthew was speaking also. He saw me speak and thought I was interesting, and I saw him speak and thought the same thing.
Over a period of years Matthew and I stayed in contact and when he, Michelle and Lee started Cloudflare he asked me to join. It was the wrong time for me and, to be honest, I had a lot of doubts at the time about Cloudflare. I didn’t think many people would sign up for the service.
I’m glad I was wrong. And I am glad that Matthew was persistent in trying to get me to join. Today there are over 13 million domains registered to Cloudflare and I have ended up as CTO. But I wasn’t hired as CTO and it wasn’t my ambition. I joined Cloudflare to work with people I liked and to do cool stuff.
I’m very lucky that my background, upbringing, parents and career have enabled me to work with people I like and do cool stuff. The cool stuff changes of course. But that’s technology for you.
It’s Terrible
When I was first at Cloudflare I went to quite a few meetings with Matthew. Especially meetings with investors and people would always ask him in a jovial manner “How’s it going?” and he would always answer “It’s terrible”. At first, I thought he was just being silly and was playing for a laugh to see how people would react.
In part, he was doing that but there’s also a lot of truth in the fact that startups are “terrible”. They are very, very hard. It’s very easy to get distracted by the huge successes of a small number of companies and not face the reality that building a company is hard work. And hard work isn’t enough. You might not have enough money, or the right people, or you might discover that your market is too small.
Silicon Valley lives in a schizophrenic state: everyone outwardly will tell you how they are “killing it” and doing so well. But inside they are full of fear and doubt. Mentally that’s a very hard thing to sustain and it’s not surprising that some people suffer mental health problems because of it. We shouldn’t be ashamed of admitting that things are hard, as Matthew did.
Silicon Valley also likes to use very positive language for things that might be a little negative or tough. One such term is “pivot”. There’s nothing wrong with changing direction or responding to customer or market demands. But face it with reality that you had to change direction. That’s OK. To quote George Bernard Shaw: “Progress is impossible without change, and those who cannot change their minds cannot change anything”.
Part 2: The Most Difficult Two Weeks
It’s always best to speak plainly and honestly about the situation you are in. Or as Matthew Prince likes to put it “Panic Early”. Long ago I started a company in Silicon Valley which had the most beautiful code. We could have taught a computer science course from the code base. But we had hardly any customers and we failed to “Panic Early” and not face up to the fact that our market was too small.
Ironically, the CEO of that company used to tell people “Get bad news out fast”. This is a good maxim to live by, if you have bad news then deliver it quickly and clearly. If you don’t the bad news won’t go away, and the situation will likely get worse.
Cloudbleed
Cloudflare had a very, very serious security problem back in 2017. This problem became known as Cloudbleed. We had, without knowing it, been leaking memory from inside our machines into responses returned to web browsers. And because our machines are shared across millions of web sites, that meant that HTTP requests containing potentially very sensitive information could have been leaked.
Worse this information was being cached by search engines. So, anyone could go to Google or Bing or Baidu and look for sensitive information just by knowing a few keywords. Luckily, for us, Google’s Project Zero discovered that we were leaking by looking at Google’s crawler cache. They informed us and we were quickly able to stop the leak.
But that didn’t diminish the fact that private information (much of which would have been transmitted encrypted) had been cached by search engines. Although we stopped the leak within 45 minutes the cleanup task was massive. It was massive firstly because we had to find what had been leaked and secondly because we had to find all the search engines with caches and somehow ask them to delete cached data.
None of the search engines had handled something like this before. We were asking for mass deletion of data and it took a long time (at least it felt like a long time) to get to the right people and start to get cached data deleted.
From the very first night of Cloudbleed I started collecting information to be able to write the public disclosure. Ultimately, when Project Zero wanted to go public, we were ready with a long, transparent blog post on the subject and were able to talk about it.
It was, by far, the most difficult week of my career. Firstly, we had the bug itself, secondly, we had the cleanup, and then we had to tell people what had happened. Throughout that week I barely slept (and I am not exaggerating) and a large team of people across Cloudflare in the US, UK and elsewhere kept in contact constantly. We learnt that it’s possible to keep a Google Hangout between two offices running, literally, for days without interruption.
Known Unknowns
The hardest thing was that we seriously did not know, at the beginning, whether Cloudflare would survive. Right at the start it looked terrible, it was terrible, and we had two questions: “What private data has actually been leaked and cached?” and “Did anyone find this and actively exploit it?”.
We answered both by extensive searching and collating of information from search engines. Ultimately, myself and others called customers and spoke to them on the phone. We were able to tell them what we’d found and statistically what was likely to have leaked.
The second question was answered by looking for evidence of exploitation in our logging systems. But there was something very tricky: Cloudflare had long limited the amount of data it logs for privacy reasons. So, we had to dig into statistical analysis of all sorts of data (crash rates, saved core dumps, errors in Sentry, sampled data) to look for exploitation.
We split into separate teams to look for different evidence and only myself and Matthew Prince knew what each team was seeing. We did that because we didn’t want one team to influence another. We wanted to be sure that we were right before publishing our second blog with more detailed information.
We didn’t find evidence of exploitation. And while serious, the data cached in search engines was found to contain little really private information. But it was very, very serious and we all knew that this could have been worse.
Although I look back at those two weeks as the worst of my career, to quote Charles Dickens: “It was the best of times, it was the worst of times”. Most of the company didn’t know Cloudbleed had happened until we went public. The morning it became public I showered very early and took a cab to the office.
Normally, the office is quite quiet in the morning and I was stunned to walk into an office full of people. People who asked me “What can we do?”. It was an incredible feeling. We printed a large poster of Winston Churchill staring down at the team saying, “If you’re going through Hell, keep going!”. Everyone pitched in.
In the middle of it someone from the press, the BBC I think, asked me if I’d changed any passwords because of Cloudbleed. I said I had not. And that was true. I didn’t change anything personally. But in the middle of that firestorm I took a lot of criticism from armchair critics for that.
Although terrible, Cloudbleed reinforced the culture of Cloudflare: openness and helping others. We were all in together and we got through it. And our customers saw that: we didn’t lose major customers, in fact, we gained customers who told us “We want to work with you because you were so open”.
Part 3: Audacity, Diversity and Change
After Cloudbleed, lots of things changed. We started to move away from memory-unsafe languages like C and C++ (there’s a lot more Go and Rust now). And every SIGABRT or crash on any machine results in an email to me and a message to the team responsible. And I don’t let the team leave those problems to fester.
Making 1.1.1.1
So Cloudbleed was a terrible time. Let’s talk about a great time. The launch of our public DNS resolver 1.1.1.1. That launch is a story of an important Cloudflare quality: audacity. Google had launched 8.8.8.8 years ago and had taken the market for a public DNS resolver by storm. Their address is easy to remember, their service is very fast.
But we thought we could do better. We thought we could be faster, and we thought we could be more memorable. Matthew asked us to get the address 1.1.1.1 and launch a secure, privacy-preserving, public DNS resolver in a couple of months. Oh, and make it faster than everybody else.
We did that. In part we did it because of good relationships we’ve established with different groups around the world. We’ve done that by being consistent about how we operate and by employing people with established relationships. This is partly a story about how diversity matters. If we’d been the sort of people who discriminated against older engineers a lot of Cloudflare would not have been built. I’ll return to the topic of diversity and inclusion later.
Through relationships and sharing we were able to get the 1.1.1.1 address. Through our architecture we were able to be the fastest. Over years and years, we’ve been saying that Cloudflare was for everyone on the Internet. Everyone, everywhere. And we put our money where our mouths are and built 165 data centers across the world. Our goal is to be within 10ms of everyone who uses the Internet.
And when you’re everywhere it’s easy to be the fastest. Or at least it’s easy if you have an architecture that makes it possible to update software quickly and run it everywhere. Cloudflare runs a single stack of software on every machine world-wide. That architecture has made a huge difference versus our competitors and has allowed us to scale quickly and cheaply.
Cloudflare’s Architecture
It was largely put in place before I joined the company. Lee Holloway (the original architect of the company), working with a small team, built a service based on open source components (such as Postgres and NGINX) that had a single stack of software doing caching, WAF, DDoS mitigation and more.
It was all bound together by a distributed key-value store to send configuration to every machine we have around the world in seconds. And centrally there was a large customer database in Postgres and a lot of PHP to create the public cloudflare.com web site.
Although we have constantly changed our software this architecture still exists. Early at Cloudflare I argued that there should be some special machines in the network doing special tasks (like DDoS mitigation). The truth is I wanted to build those machines because technically it would have been really exciting to work on that sort of large, complex low latency software. But Lee and Matthew told me I was wrong: a simple architecture could scale more easily.
And they were right. We’ve scaled to 25Tbps of network capacity with every machine doing every single thing. So, get the architecture right and make sure you’re building things for the right reasons. Once you can scale like that, adding 1.1.1.1 was easy. We rolled out the software to every machine, tested it and made it public. Overnight it was the fastest public DNS resolver there is and remains so.
Naturally, our software stack has evolved a lot since Lee started working on it. And most parts of it have been rewritten. We’ve thrown away all the code that Matthew Prince wrote in PHP from the earliest days, we’ve started to throw away code that I wrote in Lua and Go. This is natural and if you’re looking back at code you wrote five years ago and you’re feeling that it’s still fit for purpose then you are either fooling yourself or not growing.
The Price of Growth is Rewrites
It seems that about every order of magnitude change in use of software requires a rewrite. It’s sad that you can’t start with the ultimate code base and ultimate architecture but the reality is that it’s too hard to build the software you need for today’s challenges and so you can’t worry about tomorrow. It’s also very hard to anticipate what you’ll actually need when your service grows by 10x.
When I joined most of our customers had a small number of DNS records. And the software had been built to scale to thousands or millions of customers. Each with a small number of records. That’s because our typical customer was a small business or individual with a blog. We were built for millions of them.
Then along came a company that had a single domain name with millions of subdomains. Our software immediately fell over. It just wasn’t built to cope with that particular shape of customer.
So, we had to build an immediate band aid and start re-architecting the piece of software that handled DNS records. I could tell you 10 other stories like that. But the lesson is clear: you don’t know what to expect up front so keep going until you get there. But be ready to change quickly.
Part 4: Public Engagement
We don’t believe that any of our software, not a single line of code, provides us with a long-term advantage. We could, today, open source every single line of code at Cloudflare and we don’t believe we’d be hurt by it.
How we think about Open Source
Why don’t we? We actually do open source a lot of code, but we try to be thoughtful about it. Firstly, a lot of our code is so Cloudflare-specific, full of logic about how our service works, that it’s not generic enough for someone else to pick up and use for their service. So, for example, open sourcing the code that runs our web front end would be largely useless.
But other bits of software are generic. There’s currently a debate going on internally about a piece of software called Quicksilver. I mentioned before that Cloudflare used a distributed key-value store to send configuration to machines across the world. We used to use an open source project called Kyoto Tycoon. It was pretty cool.
But it ended up not scaling to our size. It was great when we had a small number of locations worldwide, but we ran into operational problems with 100s of locations. And it wasn’t, by default, secure and so we had to add security to it. Once we did, we open sourced that change, but at some point when using open source software you have to make a “modify or rewrite” decision.
We’d done that in the past with PowerDNS. Originally our DNS service was based on PowerDNS. And it was great. But as we scaled, we ran into problems fitting it into our system. Not because there’s something wrong with PowerDNS but because we have a lot of DNS-related logic and we were shoehorning things into PowerDNS, and it was getting less and less maintainable for us. This was not PowerDNS’ fault; we’d built such a large edifice of business logic around it that PowerDNS was being crushed by the sheer weight of that logic: it made sense to start over and integrate logic and DNS into a single code base.
Eventually we wrote our own server, RRDNS, in Go, that is now the code behind the largest and fastest authoritative DNS service on the planet. That’s another piece of software we haven’t open sourced. That one because it’s riddled with business logic and handling of special conditions (like the unique challenges of working inside China).
But back to Quicksilver. It’s based on LMDB and does all data and code sync. across our global network. Typically, a change (you click a button in our UI or you upload code for our edge compute product) and it’s distributed globally in 5s. That’s cool.
And Quicksilver is generic. It doesn’t contain lots of Cloudflare-specific logic and it’s likely useful for others. The internal debate is about whether we have time to nurture and handle the community that would grow up around Quicksilver. You may recently have seen the creator of Ruby saying on Twitter “We are mere mortals” pointing out that the people behind popular open source projects only have so much time. And we take a lesson from the creators of Kyoto Tycoon who have now largely abandoned it to do other things.
Perhaps Quicksilver will get open sourced this year, we’ll see. But our rule for open sourcing is: “Is this something others can use and is this something we have time to maintain in public?”. Of course, where we modify existing open source software, we upstream everything we can. Inevitably, some projects don’t accept our PRs and so we have to maintain internal forks.
How we think about Patents
While we’re on the topic of intellectual property let’s talk about patents. Cloudflare has a lot of patents. Although it might be nice to live in a world where there were no software patents it’s a little like nuclear weapons. It’s very hard for one country to disarm unilaterally because a power imbalance is left behind. If Cloudflare didn’t patent aspects of our software, then others would and would then use them against us.
So, we patent for defensive reasons. To stop others from using the patent system against us.
Working With Governments
And speaking of patents let’s talk about governments. Lots of technology companies think they are too cool for school. They don’t need to think about governments because technology moves faster than them and what do those old, boring lawmakers know about anything anyway?
Wrong. Dead wrong.
Yes, governments move slowly. You actually want them to. Imagine if governments changed policies as fast as chat apps get launched. It would be a nightmare. But just because they are slow, they can’t be ignored.
Put simply governments have tanks and you don’t. Eventually lawmakers will make laws that affect you and unless you’ve spent time explaining to them what it is you do you may have a nasty surprise.
Cloudflare decided very early on to engage with lawmakers in the US and Europe. We did this by helping them understand what is happening in the Internet, what challenges we foresee, and helping them with the technical arcana that we all deal with.
If there’s any chance that your business ends up being regulated by a government then you should engage early. Cloudflare thinks a lot about things like copyright law, the fight against online extremism, and privacy. We have to because our network is used by 13 million web sites and services and all manner of things pass through it.
Lots of times people get mad at us because they don’t like a particular customer on our network. This is tough for us because oftentimes we don’t like them either. But here’s the tricky thing: do you really want me, or Matthew, deciding what’s online? Because many times that’s what angry mobs are asking.
“Shut this down”, “Throw this off your service”. It’s odd that people are asking that corporations be gatekeepers when corporations answer to shareholders and not the people. The right answer is that if you see something you don’t like online: engage in the political process in your country.
The transparency of democratic institutions and, in particular, the judiciary is vital to the long-term survival of countries. It’s through those institutions that people need to express their desire for what’s allowed and not allowed.
How do you engage with governments? Every single government has committees and advisory bodies that are dying to have people from industry help out. Go find the bodies that are doing work that overlaps with your company, don’t be put off by how old-fashioned they seem, and get involved.
Part 5: People — Finding, Nurturing and Learning on the Go
So, let me talk a bit about people. Software is made by people. Sometimes individuals but more likely by teams. I’ve talked earlier about some aspects of our architecture and our frequent rewrites but it’s people that make all that work.
And, honestly, people can be an utter joy and a total pain. Finding, keeping, nurturing people and teams is the single most important thing you can do in a company. No doubt.
Finding People
Finding people is really hard. Firstly, the technology industry is booming, and so engineers have a lot of choices. Countries create special visas just for them. Politicians line up to create mini-Silicon Valleys in their countries. Life is good!
But the really hard thing is interviewing. How do you find good people from an interview? I don’t know the answer to that. We put people through on average 8 interviews and a pair programming exercise. We look at open source contributions. Sometimes we look at people’s degrees.
We tend to look for potential. An old boss used to say, “Don’t hire people who’ve already done the job, hire those who can learn to do it”. It’s an interesting idea. People naturally want to hire people who know how to do something. But technology changes all the time, so what you are really looking for are people who are curious.
And you won’t find curiosity by looking at degrees and qualifications. You’ll find it by asking about what people do and think. What they enjoy and what they’ve done when no one was looking.
Another thing that’s really important is to ask, “Can this person express themselves?”. It’s rare that it’s OK to have someone who can’t communicate with others. Sure, you may come across that one genius who you want to hire who only speaks in grunts. But real magic happens when teams (especially small teams of 3 to 12 people) make software together. And teams are built on communication. So, look for people who can express what they are thinking: might be through email, or drawing, or speaking.
Letting People Go
You’re also going to find that you’ve hired the wrong people or built the wrong teams. Don’t be afraid to move people around. Last year 16% of people moved to a different job inside Cloudflare (not just teams!). You should constantly be looking at your teams and asking how well they are performing.
It’s not a failure to change a team, or reorganize, or move people about. In fact, it’s a failure as a manager to NOT do that.
Don’t be afraid to let people go.
It’s sad but you’ll think someone is great when you interview them and then they turn out not to be. Or someone gets too big for their boots and starts behaving like they own the place. Sometimes people need to leave the company. This is by far the worst thing a manager has to do (to this day I hate letting people go).
Over the last few years I’ve been in the position of having to decide whether to remove people from senior management positions in engineering. Making those decisions is really hard. You might enjoy working with someone but realize that their team isn’t doing so well, or they don’t seem to be achieving what you expect from them.
I know from my own experience I’ve always taken too long to make changes. I always want to give people a second or third chance. And usually it’s been a mistake. Actually, not usually, always. It’s unbelievably tough to say to someone “I don’t believe that you are the right person to be X and so I’ve decided to replace you”. But if you do that be 100% clear. It’s fairer to the person being moved on that they know that a concrete decision has been made.
I think one of the most important things I say to people who work for me is: “You need to tell me if the job you are doing isn’t making you happy”. Because I may not realize. I’m only human after all. One of my engineers took me up on that one day and I’m glad he did. This was someone who reported directly to me: a staff engineer with a ton of experience.
One day he came to me and said, “I don’t want to work for you any more, I want to work for X on Y”. Perhaps he was nervous to say that to me but putting people in jobs they enjoy is key. A manager isn’t successful because they grow a big team, they are successful when their team builds awesome software and awesome software gets built by people who feel they are doing their best work. That should be your goal: help people do their best work. Help people grow and learn.
Diversity and Inclusion
There’s a lot of discussion in the software industry about diversity and inclusion. Many years ago, I had a small team of engineers in one of my first management jobs. There were five of us: Alice, Tanvi, Roman, Dan and me. Two women, three men. It was one of the most fun teams I’ve ever worked on because of that mixture of people and backgrounds. We built a really nice piece of software.
Lots of research shows that diverse teams are stronger, happier and do better work. You’re really losing out if you don’t have a diverse team. This is an area Cloudflare is working very hard on (and especially in the engineering team). Not because it’s trendy or cool, but because it means we’ll be a better, stronger, smarter company.
To do so we’ve looked at the language we use in job descriptions, the way we interview people, and how we source potential candidates. It also meant reviewing our benefits and internal policies to make sure that the company is attractive to all sorts of people. It’s working and I expect that by the end of 2019 we’ll be able to talk about all that we did.
Bottom line: there are great people out there from all sorts of backgrounds. Go find ‘em!
Part 6: What does Cloudflare’s CTO do?
If you are still awake there’s really one final question that you might want to know the answer to: What does the CTO do? The reality is that it means different things in different companies. But I can tell you a little about what I do.
The longest temporary job
I didn’t join Cloudflare as CTO. My original job title was Programmer and for the first couple of years I did just that. I wrote a piece of technology called Railgun (a differential compression program used to speed up the connection between Cloudflare and origin web servers) and then I went on to write our WAF. After that I worked on our Go-based DNS server and other parts of the stack.
At some point Lee Holloway decided he didn’t want to manage Cloudflare’s growing staff and Michelle Zatlyn (one of Cloudflare’s founders) asked me if I would ‘temporarily’ manage engineering. This is now the longest temporary job I’ve ever had!
Initially a lot of what I did was manage the team and help interview people. But I was still writing code. But more and more what I did was encourage others to do stuff. One day a bright engineer I’d been working with on DNS told me that he thought he could ‘solve DDoS’ if he could be left alone to work on an idea he had.
This was one of those situations where the engineer had shown they were very capable, and it was worth taking a risk. So, I said “OK” go do that, I’ll write the code you were meant to write, assign all your bugs to me. That turned out to be a good decision because he built our entire DDoS mitigation system (known internally as gatebot) which has fended off some of the largest DDoS attacks out there.
Of course, like everything else Cloudflare does, things outgrow an individual and need a team. Today gatebot and DDoS in general is managed by a team of engineers in London and Austin and the original engineer has moved onto other things. So, encouraging people is an important part of the job.
Slowly my temporary job got more and more things added to it. I was running Cloudflare’s IT department, SRE and technical operations, the network, infosec and engineering. Some temporary job. Slowly I got rid of some of those things. IT is now its own department as is infosec. Those things are far better run by other people than me!
The challenge of managing a team split around the entire globe (I had staff in San Francisco, London and Singapore) meant that new leadership was needed and so I recruited a head of engineering and SRE/ops had its own leader. Today more than 250 people sit in my overall team.
Along the way I stopped writing code and I did less and less day to day management as the leaders were able to do that. But something else became more important: things like this talk and sales.
It’s not enough to build, you have to sell
Robert Metcalfe, who invented Ethernet while at Xerox PARC, said “I didn’t get rich by inventing Ethernet, I got rich by selling it”. This is an important point. It’s not enough to have good technology, you have to get people to hear about it and you have to sell it.
One way Cloudflare markets is through our blog. You may not realize it, but we have a very, very strong brand because we write those super technical blog posts. They don’t look like marketing, but they are. And another way we market is by doing this sort of thing: going places and talking.
But frequently, what I do is talk directly to customers. On Monday afternoon and evening, I was on two long video conferences with big potential customers in the US. Yesterday, I was on a call about our partnership with IBM. This morning I did a call with a potential client in Germany before flying to Verona. So… one thing the CTO does is a lot of sales!
Nudge
One thing I am not is the source of all technical wisdom in the company. I was once introduced by a law school friend of Matthew Prince’s as “the brain behind Cloudflare”. That’s so far from the truth. There are many jobs in engineering at Cloudflare that I am incapable of doing today without an enormous amount of learning. And teams are much stronger than individuals.
I do, on occasion, use experience to push the company in a certain direction. Or simply encourage something that I think is the right technology (I did this with our adoption of Clickhouse as a column-oriented database, with Go and recently with Rust). With Rust I decided to learn the language myself and make a little project and put it on GitHub. That’s enough in my position to make people realize it’s OK to use Rust.
Finally
So, in concluding here are some things to learn from my experience and the creation of Cloudflare. Be audacious, share widely, be open, work hard, spend a lot of time finding the right people and helping them, create teams, rewrite code, panic early! And above all, while doing this remain humble. Life comes at you fast, problems will arise, the wheel of karma spins around, you’ll need the help of others. Build something great and be humble about your creation.
