The a16z Show - a16z Podcast: The Future of Software Development

Starting point is 00:00:00 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 and 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

Starting point is 00:00:46 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,

Starting point is 00:01:15 Slack CMO, Bill Macyt, Git-Hop director of field services, Matthew McCullough, and Joel Spolsky, co-founder and CEO of Stack Overflow. Steven 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,

Starting point is 00:01:50 public and private, clouds and the like. And at the same time, we have this incredible shortage of the ability to write software. And everybody wants more, and software is 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.

Starting point is 00:02:46 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 that kind of had this freemian model or basically tried the product before you use it. And I think Slack just taking that to another level. We have a freemian model where 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.

Starting point is 00:03:15 And we see, you know, every single industry in vertical, there are these best-to-breed solutions happening now. And more and more with the cloud-based model, it's easy for these teams to try it out and see if they get value. You know, and I think ultimately it's better for the customers and the companies because they're not signing these seven-figure deals and not even knowing if this stuff works or not. You know, you're doing test beds and small companies and teams

Starting point is 00:03:35 validating that the value it's providing, and then from there it grows within the rest of the organization. So, you know, 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, where is the CIO fit in 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,

Starting point is 00:04:10 especially around team communications, the more people that are going to standardize on one version it's going to be much simpler. And I think the CEO has a really critical role because you have to think about information security, compliance, you have to make sure that all these cloud-based tools that your organization using are secure and that they are actually providing value to it. There are other portions as well.

Starting point is 00:04:28 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.

Starting point is 00:04:45 of both building your own tools as well as leveraging best-sabri 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 you 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. that 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 priceless thing?

Starting point is 00:05:25 What is what's wrong? 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

Starting point is 00:05:52 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 has 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

Starting point is 00:06:14 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.

Starting point is 00:06:43 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. 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

Starting point is 00:07:23 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 and 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

Starting point is 00:07:58 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.

Starting point is 00:08:17 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 surgery 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

Starting point is 00:08:52 provenance of the code and whether that's secure and whether you can trust it. That'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, 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

Starting point is 00:09:27 customers internal or external. And like the idea that the source code is out there, other people can change it. It 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.

Starting point is 00:09:58 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?

Starting point is 00:10:21 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.

Starting point is 00:10:50 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?

Starting point is 00:11:28 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 A-B test us. And they said, okay, we like the code, but there's no test with this. We have kind of a principle that you have to have tests for any new submission that you make

Starting point is 00:11:53 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 has 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.

Starting point is 00:12:14 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 the past. past employment setups. So speaking of past employment and engineers, like one of the things that I just, I mean,

Starting point is 00:12:40 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 use would go out and just read those manuals and rewrite them and turn, you know, remove the IBM. and turn it into funness or something, as fun as IBM 360 assembler could be.

Starting point is 00:13:06 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 at priori how to use the programming environments that they're working in. So like you mean like the certifications and And like that big bracket 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.

Starting point is 00:13:44 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 StackOFlow, 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 thing that you need in any given time to make a step forward. So literally like so people show up and they just start programming.

Starting point is 00:14:10 And yet, why is that so much better? Like how, what does change? First of all, 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 you used to have that told you how to 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

Starting point is 00:14:43 with one API. All maps. Yeah. 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, their level of abstraction is a million times higher.

Starting point is 00:15:00 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, like what replaces, if you're a CIO and you're, you are building an internal system, open source or not, what replaces that sort of comforting feeling of a certification that somebody put on their, now on their LinkedIn profile that's, you know, are they, like, do you just

Starting point is 00:15:36 write, I'm good at Google now as, like, I write code? You mean, like, how do you even tell that? How do you, how do you, how do you know, but also, like, what, what is the, what, what are the metrics of knowing? 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,

Starting point is 00:15:56 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 kind of try to get a grasp as to whether this seems like a smart person. So maybe talk about what is it on GitHub?

Starting point is 00:16:25 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 really. great experience for me, and that he put in the read-me, first in the project. That was the first commit that he did was the read-me, not the code. And he said, the purpose of this project is. And I think

Starting point is 00:17:01 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?

Starting point is 00:17:34 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

Starting point is 00:18:16 the right set of skills to hire vendors, to qualify them, to know. 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.

Starting point is 00:18:45 So my background is software development. and it's worth noting that the founding insight behind Gigster was we asked ourselves, all the founders are 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.

Starting point is 00:19:10 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 back seat of the car, right? That's the experience development. 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. Yeah. 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

Starting point is 00:20:07 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 GASTRA. To 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 and do really easy to use product that will be the best experience for hiring

Starting point is 00:20:43 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 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,

Starting point is 00:21:23 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 we 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, enterprise processes aside like 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,

Starting point is 00:21:57 and that's not exceptional. 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, back-end 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.

Starting point is 00:22:20 All of these things, 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.

Starting point is 00:22:52 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 node developers, et cetera. If we didn't have Slack, we'd have to build it.

Starting point is 00:23:18 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.

Starting point is 00:23:45 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.

Starting point is 00:24:10 They built that out. And at the end of the day, when they were running 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. And so I kind of start off as a site project, and here it is kind of being the fastest growing messaging app ever. So what's neat about side projects is, you know,

Starting point is 00:24:26 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 the valley. So a lot of the people, 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,

Starting point is 00:24:47 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

Starting point is 00:25:11 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 how, and so where does like most of Stack Overflow come from in that regard? I thought what we always describe Stack Overflow is, you know, kind of, it's as a user-generated content site, there's a sort of surplus of energy that goes into that. But I think there's

Starting point is 00:25:40 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,

Starting point is 00:25:56 there's almost no stronger force than the motivation to help that person. And it's especially true among programmers. And that's where 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 contributions

Starting point is 00:26:12 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 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.

Starting point is 00:26:36 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, let me throw an example at you. So 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?

Starting point is 00:27:03 Oh. 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. I thought that right. 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 are bringing in iPhones. I don't actually know what code is running on those iPhones,

Starting point is 00:27:33 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, the entire company.

Starting point is 00:27:50 But that doesn't happen that often. No, no. It's just a statistical propensity. It's not 100%. When Stephen, Bad Code has a lot. 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.

Starting point is 00:28:08 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 process. product, all SaaS products sort of integrate almost with each other. You could imagine this

Starting point is 00:28:33 end-by-am 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 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 and what are 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

Starting point is 00:29:10 these business applications 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,

Starting point is 00:29:42 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

Starting point is 00:30:14 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? We're writing code, and today we're looking at about 40 million people every month, human beings, unique visitors that appear to be using Stack-Oflow 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

Starting point is 00:30:48 of geography or base or spoken language very much. The first thought is to what the function looks like. Are there tests around that? that adds 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,

Starting point is 00:31:14 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, you know, 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, you know, 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

Starting point is 00:31:49 better, you know, 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 none, so you have to hire people. I think the world is moving so that anyone can create that value

Starting point is 00:32:06 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 so anyone can provide that value. And I think at Slack, we're trying to viewing it the same way, where we integrate with over 100 different business apps.

Starting point is 00:32:29 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

Starting point is 00:32:40 the future software engineering. Thanks. Thank you. Thank you.

The a16z Show - a16z Podcast: The Future of Software Development

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.