a16z Podcast - a16z Podcast: The Future of Software Development

Episode Date: January 5, 2016

As software becomes core to every industry, there is a need for more and more software development across practically every department in a company. But as anyone who has tried to get quality software developed knows, that has given rise to a supply and demand problem. Leveraging open source software is a big part of the solution to that problem, but venturing into the open source world raises all sorts of questions for most companies. For example, how do you engage as a company in the open source community; what are your obligations to the project; and if you are hiring a development team what clues ought you to be looking for to get the best developers? And what are the developers looking for? And in the end, who’s responsible and accountable for the all this code flowing around? In a discussion from the firm’s 2015 Tech Summit, Steven Sinofsky digs into all those questions with a panel that includes Roger Dickey, founder and CEO of Gigster, Slack CMO Bill Macaitis, GitHub Director of Field Services Matthew McCullough, and Joel Spolsky, co-founder and CEO of StackOverflow. The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

The content here is for informational purposes only, should not be taken as legal business tax or investment advice or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Welcome to the A16Z podcast. I'm Michael Copeland. As software becomes core to every industry, there is a commensurate need for more and more software development across practically every department in a company. But as anyone who has tried to get quality software developed knows, that has given rise to a supply and demand problem.

Leveraging open source software is a big part of the solution to that problem, but venturing into the open source world raises all sorts of questions for most companies. For example, how do you engage as a company in the open source community? What are your obligations to the project? And if you are hiring a development team, what ought you to be looking for to get the best developers. And on the flip side, what are the developers looking for? Stephen Sinovsky leads a discussion from the firm's 2015 Tech Summit on the future of software development, where he digs into all those questions with a panel that includes Roger Dickey, founder and CEO of Gigster, Slack

CMO, Bill Macyt, GitHub Director of Field Services, Matthew McCullough, and Joel Spolsky, co-founder and CEO of Stack Overflow. Stephen Sinovsky starts things off. The panel today is about the future of software development and not just for IT. Sorry, didn't mean it in any negative way. But one of the things that's just so fascinating is that we're in this time when we both have an incredible surplus of software, the ability to download or to use SaaS applications and to roll them out no matter where you are in an organization, public and private, clouds and the like.

And at the same time, we have this incredible shortage of the ability to do that. to write software, and everybody wants more, and software's eating the world, and every industry, it's amazing to see this kind of interesting balance between a supply and a demand. And so I thought we'd sort of explore that a little bit, and then really just dive into how the new world of cloud and SaaS and things is really changing the actual creation of software in a really fascinating way. But first on, just on the supply side, I thought we would just sort of begin by, like, asking, you know, what's so different now in terms of how people can just go and acquire products and start to use them? And where does the CIO sort of fit in there?

And what do we see going on in that space? Maybe start with Slack, which is sort of well known for being one of those kind of products. Yeah, it's a great question. I think the distribution model has changed tremendously over the last 10 years. I worked at sales search for about four years and I think they were one of the first ones I kind of had this free-me model or basically tried the product before you use it

and I think Slack's just taking that to another level we have a freemian model where it is not the trial is not time-bound or user-bound so you can have 2,000 people on it, it can be free and I think ultimately it's just a much more frictionless way to experience software and we see every single industry in vertical there are these best-to-breed solutions happening now

and more and more with a cloud-based model it's easy for these teams to try it out and see if they get value. I think ultimately it's better for the customers into companies because they're not signing these seven-figure deals and not even knowing if this stuff works or not. You're doing test beds and small companies and teams validating that the value it's providing and then from there it grows within the rest of the organization.

So historically the CIO has been viewed as like the guardian and from the most part the creator of the software, at least the selector of the software in an organization. organization. Where is the CIO fit in, and actually in that role you said, you know, in the example you gave of a department trying it out, does the CIO join in the trial? Where does, where do you see that working, not working? Yeah, I mean, we like to bring the CIO in as early as possible, because I think there are, especially around team communications, the more people that are going to standardize on one version of it, it's going to be much simpler. And I think CEO is a really critical role because you have to think about information security, compliance, you have to make sure that all these cloud-based tools, like, your organization using are secure and that they are actually providing value to it. There are other portions as well. You know, when you are set to aggregate that, all these teams together, you can get price savings, you can go about negotiating through there and working with the procurement and legal

teams. But I think the CAO has a huge role. But ultimately, you know, the CAO, you are serving your customers, and your customers are your internal employees. And I think that's going to be a mix of both building your own tools as well as leveraging best-of-bury cloud solutions and the platforms they provide. Well, you said something that's super interesting. I kind of want to push on a little bit

because I want to get a sense for how folks think of it. I don't know if all the CIs want to be sort of the price negotiators and maintainers of a price list. So where is the architecture fit in and where does the standardization? These are the words that the CIA used to be comfortable with.

Sure. So like security, I think we're all on board. You know, you could bring in a product, but you're still accountable for the security of something you didn't write, that you didn't approve, that you didn't bring in that you don't want. But how about the price list thing?

What is, what's... Yeah, I don't think we're getting the CIA involved in the pricing negotiation. There's a lovely procurement team that's going to handle that, and they negotiate very well. But it is, it's a critically important function. You know, essentially we're enabling

every single team out there with the tech stack that is going to define their productivity and the overall company's vision and ability to achieve that. So, again, I think it's like we like to work with the CIO And we like to think about how we can make their lives easier from a provisioning standpoint, from a compliance standpoint, from an admin standpoint, from a reporting standpoint. And again, the earlier we loop them in, generally, we see the better the process goes. So one of the things that is really made products like Slack and most SaaS products, frankly, possible has been the rise of open source.

And the way that it's packaged up as a service and integrated and built upon is fascinating. and that's probably really changed the in-house IT development. And so, you know, one of the companies represented here at GitHub sort of houses most of the open-source software in the world. And it's a crazy thing to think about when you start to realize the scale. Maybe just for fun, like, what is the scale right now? It's unfathomable sometimes. We're talking about 35 million projects right now and 11 million users.

So slightly more than an average IT department? Slightly more, though there may be some represented here that are close to that number. But when you think about that, we're talking about creating projects that are of scale of kind of nation-state level. So these, when we think about projects from before, you're talking about scale here. We have 10 people, 100 people, maybe 1,000 for really dramatic big project. But now we're talking about 5,544 people. I looked up the number just before I came on stage, working on the Linux project with contributions there in that GitHub repo in the end. And then we see companies that are talking about projects that potentially have tens of thousands of collaborators, customers of ours.

So we've literally changed the number of how projects get constructed to be web scale, just like the users that we've thought about for mobile devices. So how should a CIO think about engineering related to open source? Like how do they think about using it when, you know, even let's just ask about that and then maybe dive into sort of regulatory compliance. engineering and source code management, after we just, like, what's the basic thing? Do they just let their IT group go out to GitHub enlist and start syncing? Well, let's take it a piece at a time. So for consumption of open source versus contributing of open source versus the use of the concept of intersource, we're starting to be able to split those apart and speak more articulately

to all three. The consumption of open source is the one where if anyone here in the room says, my team uses no open source from GitHub, we should have a talk afterwards because they do and you're just not yet aware of it, so we need to raise the awareness. I speak from experience. That is actually true, even in the world's most largest proprietary software company. We've made those discoveries and some of those conversations have been awkward. But then later, when thinking about contributing to it, what you want is the highest quality

practitioners and keeping their skills sharp, much like you want your doctor constantly performing surgeries so that when it comes to you, he's or she is well skilled at it, you want the same thing of your software developers and giving them an outlet through open source to contribute back to it, is to keep those skills sharp in areas that may not necessarily be well fertilized inside the business that you work. And then lastly, you say kind of the governance and the provenance of the code and whether that's secure and whether you can trust it. It's somewhat of a new frontier. We don't have all the answers there yet. There are companies that are trying to give that some credibility and stability. There are organizations

who vet that open source on their own and only accept certain patches in. But I think that in some ways, that's the frontier of the three that we're talking about. What would you say to a CIO that historically, you know, guarding the source code for their core line of business applications was an incredibly important part of not just the job, but sort of responsibility to the audit committee, responsibility to their ultimate customers, internal or external. And like, the idea that the source code is out there, other people can change it, like feels like pulling the rug out from under me as an executive. How do you offer advice or guidance or even think about that strategically?

Well, I have two responses to that, Stephen. First off is, with the consumption of so much open source, you have to look at that as getting your base platform at a higher elevation. You're starting at 10,000 feet instead of starting at zero to build the stack up each time. Everyone has democratic access to that same 10,000 starting foot kind of point, whether it's through Twitter bootstrap or Spring Boot, or they're using any other framework that's out there for a different language, play framework for Scholar or the like, they're getting that first elevation. So that's equal.

Next is what you're going to do with that afterwards. Are the extensions that you create to it going to be proprietary? Do you keep those in-house? Does that somehow give you an advantage? But taking of upstream patches seems to be a very significant concern of time and effort. And so I say that you're actually better to think about how quickly you can release product to market and less focus on trying to keep your code close to the vest and inside. Many cases, I can take code from many of the companies represented here, and it's difficult to get it to build. I'm pretty sure it's not a concern

that there's a secret algorithm in the vast majority of the business processes that we write. I'm more interested in it getting out to customers and consumers and creating value for the business division that wrote it than I am worried about some other business possibly seeing the function that we wrote in Java. I want to push on that a little bit, just because I feel like folks are still going to wonder

a little bit, wow, it's not just that it might be our secrets, but if in a world where people can contribute, do I now have to review every commit that other people make? And, you know, am I undoing it? And like, then am I going to get the ill will of the community because we don't accept their change? Where does the community fit in with open source that, as a business, you want to rely on? I'm archiving a thread even just from this morning that includes some senior executives from really interesting companies that are contributing to open source facing this very question. And there were no definitive answers in that thread. Because some patches came across that added valuable contributions, but they didn't

have tests. This is kind of an easy way AB test us, and they said, okay, we like the code, but there's no tests with this. We have kind of a principle that you have to have tests for any new submission that you make here, so we're going to decline it, and the response was pretty negative and pretty brash. Fine, we're never going to help the project again. So what I've noticed is that this is gone from an engineering and a creativity and a finance discussion to being one of kind of emotional management of employees that are at an extension of your core business. They don't quite work for you. They work with you and you have to think about their impact and you have to think about how managing this brokering of code that you consume and is in the public will affect,

do I take the patch? Do I take this one and get it reviewed by somebody internally? Lots of hard questions that are blurry compared to past employment setups. So speaking of past employment and engineers. Like, one of the things that I just, I mean, I'm old enough now to remember, like, learning my first system involved, you know, 15 feet of binders and manuals. And that was the definitive source of everything. Like you, there was no other information to be had. In fact, people who wrote books about the systems that we used would go out and just read

those manuals and rewrite them and turn, you know, remove the IBMness and turn it into funness or something. as fun as IBM 360 Assembler could be. But how does open source and just the whole change in the environment alter just how programmers even learn what to do? And I think Joel has a lot of work and insights into that. Yeah. So I think that what we think is that people have given up from learning a priori

how to use the programming environments that they're working in. So like you mean like the certifications and like that big rack of red books? let alone the documentation. I think they start by writing code or by cutting and pasting code. They don't even go to the books. They start by, we think of it as sort of page faulting in knowledge.

So you actually type, as you code, you have problems. Nerd alert, sorry. You type your problem. Whatever problem you hit, you type into Google and you get a result, hopefully from Stack Overflow, if we've done our job. And you cut and paste that into your source code, and then you continue.

So you're essentially learning literally only the exact, acting that you need in any given time to make a step forward. So where does where so it literally like so people show up and they just start programming and and yet why is that so much better? Like how what what just changed? The first thing that changed is that the systems that we're coding against are a million times more complicated. So those 15 feet of binders that used to have that told you had a program a mainframe computer, you know, we're telling you how to format numbers in a certain way. And that's only like a piece of, let's say, credit card processing. So today,

with one line of code, you might accept and process a credit card. And so the level of complexity that you're working at, you might summon an Uber vehicle with one API. All maps. Yeah. Or display a map and figure out what points of interest to display on it. And so you're working at a much, much, much, much higher level because the libraries have been built up over the years so that as a programmer, the level of abstraction is a million times to hire. And so as programmers, we are much more empowered, but you're also working with these systems that you may never have seen before. And so somebody may have to dive in and do credit card processing today, someone in an Uber car tomorrow and then display a map on the third day.

And that would have taken a huge team of people, you know, years to figure out in the past. So where, where, like what, what replaces, if you're a CIO and you're, you are building an internal system, open source or not, what, what, what replaces that sort of comforted, comforting feeling of a certification that somebody put on their now on their LinkedIn profile that's a you know are they like you just write I'm good at Google now as like I write code like how do you even tell that how do you how do you how do both how do you know but also like what what is the what are the metrics of knowing yeah yeah I don't know it's real hard to tell it's hard to tell there are these sort of kind of alternate qualifications but I think that it's really looking at a programmer's

public work now that's relevant. And so just like you wouldn't hire a designer without looking at a portfolio that they brought you, when you're hiring a programmer today, you're likely to look at the open source contributions they've made on GitHub, the questions that they've answered on Stack Overflow, blog posts that they've written, presentations that they've given, and, you know, kind of try to get a grasp as to whether this seems like a smart person. So, oh, so maybe talk about what is it on GitHub, how is your resume on GitHub now? So a lot of your work, when we think about the past employment experience, is I'll bring you

maybe a project that I worked on before, but you've written a summary about that, and I take your word for it that you were the lead architect on that, and I don't really have any sense of how you work with others or how you write code. But when you look into the history of somebody's project on GitHub, there's so many different things that we can discover. I hired somebody last year, and I think this was a really great experience for me, and that he put in the readme, first in the project. That was the first commit that he did was the readme, not the code.

And he said, the purpose of this project is. And I think about that person when I hired that, this is a person who knows where they want to go before they start the action of going there. And that's the kind of strategic person that I would often like on my team. And I think about that. That was in the commit history in a GitHub repo, and that was an excellent signal as to the behavior of the person that I'm not sure I could have discovered in a typical interview process or at least not be confident about the result.

So now we've got this world where there's access to all of this source code. It's super high level. But how do we use those together to solve the demand problem? Like where are people going to get all of this software that they need? And so like we, you know, as you all know, for sure, like we see many of you in the EBC and we constantly get asked, you know, basically help us to build Silicon Valley development teams, help us to get all of these skills because we need these apps. I was talking to a consumer goods company, and they were asking, like, our marketing group in another country just wants to build a consumer engagement app. They just want an app in the store that engages them on the

products that they build. They go to IT. IT says, that's not what we do at all. Then they, sorry, and then they say, well, we'll get some vendors. But they don't even have the right set of skills to hire vendors, to qualify them, to know to go to GitHub and count their stars and commits. And even if they could, then they have to basically become the product managers for that. And so then along comes Gigster and with a process. And so I feel like it's worth just walking through a little bit, like how you stitch together all of this technology to build both, to solve both the supply and the demand side of software.

Yeah, certainly. So my background is software development, and it's worth noting that the founding insight behind Gigster was, we asked ourselves, all the founders or software engineers, we asked ourselves what's a product we would be willing to freelance on, right? Because the best developers in the world, like I mentioned earlier, they don't want to be in a marketplace bidding against development shops overseas. They don't want to have to do client management. They certainly don't want to work for development shops. The best developers want to work for a visionary, inspiring company like Google, or they want

to go start their own company. We find that we're able to recruit those people actually very easily because if you work for a large, visionary, inspiring company, you're stuck in these long-cycle roadmaps, and a lot of these developers find themselves kind of getting bored at work, particularly the smartest ones, get bored and they want to do side projects. So why not get paid for those side projects? So you can use the Uber analogy, which I think works very well for us. So imagine the driver's side of the Uber experience, but put a wall between the front and backseat of the car, right? That's the experience developers want. They're fine taking somebody for a ride, they just don't want to have to interact

to that customer and they want to choose they really don't. It's just a social statement about engineering. Don't worry about it. Believe me. You know, they don't want to go find

their own passengers, so to speak. They want an app to just say, hey, we've got somebody for you, and they want to choose when they're online and when they're offline, right? So we find that to the Silicon Valley point, we're able to get a lot of these developers that think they're too cool for school,

they quit their job at Google and they go start their own company, but now they don't have that Google salary anymore. And they're kind of hurting for that, so they want a way to make money. So we're actually funding all of these little startups that never work through a degree. So that's, you know, that's the supply side. And that's, you know, like I said, that was the founding insight. And the thesis was if we can get really good talent and we can sort of package it into a really easy to use product, that will be the best experience for hiring freelancers. So to kind of, the more consumer side

of it. For new customers, it's a very easy experience. It's a much easier experience for existing customers, but I'll mention for new. For new customers, you get to the site. We try to design it like a consumer product. So that's, again, our background is consumer products. We try to take the concept of an agency or consulting firm and say, you know, what do you have to do? What's the absolute minute? What's the shortest path from, I want this built to having it complete, right? So the shortest path is this. It's, you get to, you get to, to the website, you click some button, you're chatting with us, we call them

sales engineers, they go through, they ask you a few questions, and they basically, their job is to fill in the gaps. So they're asking you, you know, okay, what do you want to build? Let's say you want to build an Uber for pizza, where the customer can tap a button and easily get a pizza, right? Okay, so, you know, what platform is this, iOS or Android? Do you need

to see a map or not? Are there multiple types of pizza, et cetera? They'll ask you those questions, and they'll come back and say, okay, that's $15,000, click here to pay. At that point, you know, enterprise processes aside like, you know, POs and contracts, you can literally just click a button and get started. So we've seen people start $40,000 projects after being on the website for just two hours. And that's not exceptional. You know, we're able to facilitate

these very large projects very quickly. Then once you get into the experience, like Stephen mentioned, you're given a product manager. So we don't just give you engineering talent. We give you a product manager. We give you a combination of front-end, backend engineers, designers, and we've vetted all these people very carefully so you don't have to. We also manage the project so you don't have to. All of these things, you know, hiring, retaining, managing engineers, these are all very hard things and we do this for customers. So the interesting part about this, what attracted us to this problem is there are a lot of ways to use software to kind of optimize all the processes that happen inside of a consulting firm or agency. So that's what we're trying

to do is kind of optimize lower cost and make it a more regular streamlined, repeatable experience for customers. Which of the software here do you use to get the job done? Absolutely everything. So we have like 300 projects on GitHub. We have an internal GitHub so we can reuse code from certain projects to make things more efficient. Everyone's on Slack.

So our entire development team is in Slack. Whenever we start a new project, we have 200 projects going on right now. We start a new private room in Slack so that the team can collaborate. We also have horizontal rooms for all the PHP developers, all the no-due. developers, et cetera. If we didn't have Slack, we'd have to build it. So Slack is absolutely a huge enabler for our business. And of course, they're on Stack Overflow all the time, I'm sure. Well, there's an interesting cultural thing that I think is just worth sharing. And I actually love everybody to sort of chime in if it makes sense for you, which is, like, you just

casually mentioned this notion of side projects. And side projects are actually a really huge element of the Silicon Valley culture. In fact, maybe a little bit about where Slack came from even to begin with. Yeah, Slack for those that don't know, it was a failed gaming startup. The founders have actually failed twice at creating a game. One pivoted into

Flickr, the other pivoted into Slack. But it really just kind of spoke to it. It was interesting when they created the game. They started to do, they used IRC in an internet relay chat, and then they kind of noticed that, you know, they wanted to send offline messages, so they built that out. They wanted to be able to archive the messages. They built that out.

And at the end of the day, when they were out of money, we went back to Andreessen and the others and said, hey, you know, the game's not working out, but we tend to do everything in Slack right now, you know, and so I kind of start off as a site project, and here it is kind of being the fastest growing messaging app ever. And so what's neat about side projects is, you know, I sort of remember growing up, like hearing about 3M and being able to innovate on Fridays and do whatever you want, and then Google picked up on that, and it turns out it's really institutionalized across all of the valley. So a lot of the people, there actually, there are side projects, too, that they work on.

They're not just only at startups that they were trying to make up for lost salary, but they are people from a broad range. That's right, yeah. So some of our engineers are actually moonlighting from full-time jobs. Some of them have startups, and then they use Gigster on the side to kind of pay the bills. I might say it's almost a Maslow's hierarchy of developers' needs, and it's kind of an important thing to think that it's not motivated in the same way that other business individuals in an organization might be.

there is a need to create and innovate and experiment and sometimes fail that is rather sustaining in nature. And so when you remember that, it makes some of the behaviors a lot more explainable. Joel, isn't one part of it also the desire to just share and teach other people? And so where does most of Stack Overflow come from in that regard? We always describe Stack Overflow as a user-generated content site, there's a sort of surplus of energy that, goes into that. But I think there's a certain element of when you're uniquely qualified to answer somebody's question and to help them, it's very, very motivating. If you can do three minutes of work to answer something that maybe 10 people in the world know the answer to, and you can save

somebody hours and hours of discovery, there's almost no stronger force than the motivation to help that person. And it's especially true among programmers. And that's where kind of all open source comes out of that. But I think that our goal with Stack Overflow is to give you a very, very small unit of contribution. Answering a question is one thing, but an even smaller unit of contribution is just upvote an answer that you see that's correct. Just like, thank the person that provided that answer, move that answer a little bit higher up in the search rankings, and, you know, help, you know, with just one click, essentially, you can kind of make a small contribution. So kind of now want to give, we painted this great world. You basically, there's all of this

amazing software. You push a button, and software shows up. But from a CIO perspective, there's still a lot of desire and accountability around control. And so where does control fit in? Like, I'll let me throw an example at you. That's like, so I, you know, the employee says I copied the source code example from Stack Overflow and it had a bug in it. And now that bug is all over our code and the internet. Yeah. Like where is accountability for that?

It's not a true question like that. I mean, I think that, you know, there may be CIOs that is still operating in this world of kind of NASA-1950-style engineering where you just built everything. I don't know. But at some point, you start to treat the units that you're dealing with as either atomic agents, which is, all right, fine. People bring in iPhones. I don't actually know what code is running on those iPhones. up to almost biological where you start to think of

like, well, we've got some trees in the building and every year some percentage of them gets sick and we have some source code in the building some of which we brought in from outside and every year some percentage of it represents a statistical propensity to, you know, blow up the entire company. But that doesn't happen that often.

It's just a statistical propensity. It's not 100%. When Stephen, bad code has no provenance and good code everyone wants to claim creditors? It is, I mean, in a sense, of course, it's statistically true, and it's also very much on everyone's mind. Like, how do you balance this? How do you think about that? Even from just the standpoint, like, one of the things that I find unique about all the products here is the openness that they all have, even within themselves.

The openness is a new level. Like, one of the things that's so fascinating about Slack is this massive community of people building extensions and integrations so that there's not another SaaS product. All SaaS products sort of integrate almost with. each other. You could imagine this N-by-M sort of matrix where they're just integrated. We had one the other day where like Amazon released sort of a community released a buy it now sort of thing on Slack and now it like you just be in Slack, someone could do a link to something and you could buy it. Where to, but the neat thing is those are very empowering. So where does accountability reside? And how are modern SaaS apps even helping engineers to make sure they do

the right thing in terms of those, that type of integration? Yeah, I think a lot of these integrations, Slack is approving, and we're reviewing and we're vetting. We announced today our slash commands, which basically allows it easy for any of these business applications to integrate with Slack. And Lyft was a cool one. So you can basically do backslash lift, say, my home, and boom, you've got a lift coming straight there. I don't know. I mean, I like to think of the world more through just the value you're creating. And I think, you know, in the CIA role that essentially you're trying to create value.

And, you know, you want to leverage the ecosystem of both your internal team, your external team, but do it in a safe and compliant manner. And I think that's the juggling act that, you know, that role has. So let me wrap up a little bit with one philosophical question, and I'll take any takers on this one, which is, is being a software engineer a new form of literacy that everybody's going to have to look for in terms of who they hire? Or is it going to be the old kind of manufacturing,

and we're going to look back, and they're all going to be eaten by robots? Well, I'll kick that off. by saying that when we started building Stack Overflow, we did a lot of research on how many software developers there were in the world. And the conclusion seems to be 9 million people that called themselves software developers in the world. And we had at the time 6 million users.

So we thought that was a pretty good percentage of them. And then we got to 9 million users, and then we got to 20 million users. And we thought, who the heck are all these people writing code that we never expected were writing code. And today we're looking at about 40 million people every month, human beings, not unique visitors, that appear to be using Stack Overflow every month.

So the number of people writing software is probably around 40 million out of, you know, only 9 million people that call themselves developers. Still not in the billions, but a pretty large number. And if you look at the contributions on a GitHub project, people don't really think in terms of geography or base or spoken language very much. The first thought is to what the function looks like. Are there tests around that? Does it add some value to the project?

it's interesting how delayed the geographical or associative of where you work, the association with where you work, is in the thinking process. I rarely hear it mentioned in open source projects. Yeah, I think there's kind of an over-emphasis on this, you know, everyone should learn to code, you know, mantra that you see a lot in the press. To me, I think software literacy is about, it's just about recognizing that software is the new business tool and try to understand how software's built,

because if you know how something was built, you'll be a better user of it. And perhaps that and also thinking like a software engineer. So one of the reasons that engineers tend to make good founders is because engineers think in a certain way. So I think understanding at least how engineers think and being able to think in that same kind of process-driven and logical way helps everyone be a little better at business,

even if they can't code themselves. Anything to add? I'm not a software developer. I'm the CMO, so. So how's your literacy? I do think, though, if you... You hire non-sault. You have to hire people, so...

I think the world is moving so that anyone can create that value and that you don't need the hardcore development language skills. And I think the same analogy is like on the business analyst side. There used to be a time where only hardcore analysts

that knew the data warehouse could extract through SQL queries and pull it out. And it's shifting with BI tools now where anyone can be an analyst and anyone can provide that value. And I think at Slack we're trying to viewing it the same.

where we integrate with over 100 different business apps. It's easy to create those. There's an add to Slack button. You can add those integrations on your own. You don't have to have these massive technical skills to create that value. Cool. Well, thank you very much. It's been a great chance to chat about the future of software engineering.

Thanks. Thank you.