In this episode, you'll learn how agencies can work better with institutions to build service design capacity, what is the future role of agencies when everything goes in-house, and finally, where and how can frontline contribute in designing services. And here is the guest for this episode. Hi, I'm Sarah Drummond and this is the Service Design Show. Hey, my name is Marc van Tijn and this is the Service Design Show. If you want to create more impact as a service design and change the world for the better, then you've come to the right place. Because on this show, you'll get the chance to learn from the success of some of the world's best service designers. We talk about topics ranging from design thinking, customer experience, organizational change and creative leadership. If these are the topics you're interested in, be sure to know that we bring you a new episode every two weeks on Thursday. So if you don't want to miss anything, subscribe to the channel. My guest in this episode is Sarah Drummond. Sarah is a managing director of a design and strategy agency called We Are Snoek, which she co-founded back in 2009 with Lauren Kirby, who was also a guest on the show. So for the next 30 minutes, Sarah will be talking about how agencies can work better with institutions to build service design capacity, what is the future role of agencies when everything goes in the house, and finally, where and how can frontline contribute in designing services. So that was it for the introduction and now let's jump straight into the interview with Sarah. Welcome to the show, Sarah. Hi Marc. It's so good to have you here because we had the other co-founder of We Are Snoek. I think in the second or third episode on the show and now we have the other co-founder of Snoek, so happy to have you again, Sarah. I'm really happy to be here. Thanks for having me, Marc. The question that I ask everybody on the show, the first question is, do you actually remember the very first time you met service design? That's such a historical question for me. Yes, it's probably nearly 10 years ago now, I think, and I was studying product design actually, so I met it as a student and I met it in a way that I didn't actually know what it was, so I come from a background of designing lampshades, coat hangers, bicycle stands, drawing, everything. And we were asked when we were at the Glasgow School of Art to come and look at a public body that sits under Scottish government's remit and ask to look at how their business was performing. And we went about it in the same way any designer would that you create a chair or a coat hanger. We interviewed people, we tried to understand their experience. We used a lot of visual language to map how the whole business worked. We prototyped some tested new concepts. They happened to be servicing and we presented it back to the government and it was only really during that process of some extra teaching that someone said this is what service design is and so from then I was hooked and ended up working with them actually over a course of about two years, so that's my first experience. There was a spark or epiphany, the moment of enlightenment. Yes, I think it was really interesting to be a group of product designers traditionally trained at making physical things to come across a new form of material which is people and relationships and other things. Exactly. Cool. Sarah, you gave me some really interesting topics that we're going to discuss in the next 25 minutes and I gave you some question starters and we'll co-create the topics and the questions as we go along, right? Are you ready? I am so ready. Alright, let's start with topic number one and I know you've been thinking a lot about this one so this should be easy for you. Topic number one is building capacity for service design. Which question starter do you have? I'm going with this one is how can we build capacity for service design? So this is really big for me and the reason is that before I started SNCC Florin, I'd been working for a non-departmental public body that is with the Scottish government that I previously mentioned and it was really difficult with different agencies coming in doing the work with us that they would leave and we wouldn't really quite know what to do and the agencies that did do it really well were some really great service design organisations. They left us with I think some capacity to be able to take on their work and their knowledge but most of the time and the work I've seen when I've worked with other agencies now is SNCC. They haven't been given the capabilities to continuously design great services. In fact, they've been left in the dark with the agency or organisation coming in as an expert. So I've really been propelled the whole time to think about with SNCC and with any other work in the industry that really we should be thinking about building the capacity for these organisations and what I mean by that is thinking about how you get people to understand the concept of design to begin with and not even design as service particularly or design as product or interaction but understanding that design for me anyway is about making sure that the form follows the function so it's about usability. So the first thing really about building capacity is that quite simple understanding and then at second level it's about really thinking about in a service design context well what does service mean for us? So building the capacity of a consistent language and understanding of that and then really kind of thirdly is then having the skills and the sustainability strategy really to make that a reality. So training in design skills so that you and it's not about everyone becoming a designer for me it's really about giving everyone the capacity to be able to design moving people from not just they don't have to become design experts but from design basics into design fluency and then making sure that you design ways in which the organisation can create the products that allow design to be scaled and sustained. So that's what I mean and I think it's a really big question for me of the industry now actually that works in service design to be focusing in on this question. So a super relevant topic at this moment and so many questions that go through my head now that you're talking about this and one of the questions is for instance we encountered this a lot in our own projects too and then the question becomes but you're saying we should make everyone understand design we should make everyone understand services but is it really everyone or have you found that there are different groups of people within organisations that are more open to it and are more important to actually train or? Yeah definitely I think I can answer that in about three different ways it depends on the stage of design maturity I think of an organisation and also I think that aligns really relevantly now with their digital maturity as well because services are so often are pretty much centred around the digital capacity and thinking of an organisation whether that's how they deliver their services to how they run them in the back end so one of the things I say first and it's a bit of a hack really if you're introducing design to an organisation is to go and find the team or department within that organisation that can deliver the thing you're going to design so for example most recently we just worked with Cork County Council that we presented with at the service design network conference in Madrid and it was a wonderful presentation because I felt really proud that they knew exactly what they're talking about they're designing and delivering really good services and when we met Cork they actually had a lot of senior buy-in because we worked with them to look at this new customer transformation team that had people who were actually building the digital front end of new services so they were going through a process of digital transformation taking processes that were offline and making them online and we had a bit of an issue and we've laughed about it now that it was originally a lift and shift attitude which was take something that might not be that great offline you just put it online and it might still not be that great and for me the training of those guys was so instrumental to this work because it meant that when we went through the user research and the structuring of what the service should be and the prototyping of it they were able to make it live at the prototyping stage and then take it into a proper live later on so in the first instance who should we train I think for me it's the people who have the ability to shift the product to execute Exactly Or else you end up with a bunch of knowledge that's maybe really interesting but isn't acted upon within the organisation but then I think to that extent you also need an early stage and throughout is a senior buy-in and I think that that won't be new to the show or any particular insight but that senior buy-in needs to be brought along across the whole journey and particularly what we're finding quite difficult actually is to help senior leaders once they've had their first excitement about it they tend to think about the beginning of this work is then to make the right and significant investment at a later stage to think about sustaining and growing those capabilities because it's easy to do it it's easy to do a one-off service design project but it's really hard to keep it going right? Yeah to keep it going but to also see that you have to invest behind the actual design of the service in the products that make the community of people within an organisation come together around design and that's lots of things so that's things like show and tells networks of people interested in design coming together it's platforms in how you analyse the data of how your services are performing the investment into those kind of products so it's a lot of stuff behind the scenes it's difficult to sometimes put an exact number on the efficiency it might create or the impact it might have on the end user What is your biggest question related to building capacity? What would you like to... we're doing this episode in December of 2017 what would you like to better understand in 2018? So for me... Regarding the topic Yeah what I'm really interested in now are the different models in which organisations are using to embed design not necessarily the process that they're going on but how those organisations are structured so for example I've met organisations who have put design completely into their front line have put it into delivery mechanisms and product management roles some of it is in corporate service roles and I don't think there's any definitive answer at all it's what works for each organisation but I'm just interested to know from different people how it's being used and structured within an organisation Super interesting we should do a special episode on that we're going to move on to topic number two and that's a really really important topic because it's about us and about our future and you formulated this topic as our future role Yeah so I'm going to go lucky dip on my questions here but let's see how this works out I think it says how far so how far can our future role go in service design and I brought this topic up because I regularly have an existential crisis about running an organisation and there is a consultancy format and I am in no doubt and please come to me if you want any therapy if you also run a consultancy but there are others out there who probably feel the same so why an existential crisis so for me because I started briefly on the inside I saw the value of having design on the inside of organisations and we built SNCC around building capacity what we were talking about in the first instance really trying to make sure that goes inside organisations existential crisis is because I really believe that yet I run an organisation that sells consultancy as an expert role to the companies so now I'm starting what we've pivoted our work around is that thought what I'm then starting to question and I think other agency leaders might be concerned about is what happens when everyone goes in house what happens when organisations no longer want to pay for consultancy and how far can we take this service design thing before we all realise that ultimately it's better in house or is it? what are your thoughts about that? so my thoughts are that I think there will always be a role for consultancies and part of our job is about doing the next thing so right now what we should be switching on to is making sure that no more massive PowerPoint slide decks are produced that we really craft our practice around the building capacity of organisations I think there's a huge role in training we know from major speakers across government anyway there's a deficit actually in the design talent that is ready to take on these service design roles to take on roles around interaction and more widely the user experience of users really for the services that government and public sector deliver so for me it's a call to arms and then now to organisations to really help those organisations build those capabilities and to be perhaps this is not a concern that I think anyone is right now but to be quite humble actually about what we can do so to remove ourselves from expert role into the training and the skilling up of people to understand and be able to use design is something that is for good user experience and then I think our role in the future is about getting smarter about what we do can we be designing the tools of tomorrow that allow others in the organisation to be able to design so you've seen certain consultancies I think normally recently released a product around being able to design better I think it was better interfaces we see companies building things like their own products that we transfer and I'm not saying that's specific for service design but I think we can be designing tools now that help do the job better we've seen this with people like Mark Stichthorn and the work they do it smartly so we can be getting smarter now actually about helping organisations have the right tools in place by building them for them I don't think we'll be lost really our work is probably going to shift that's what I'm seeing happening already within well I think over the last three to four years it's starting to shift from getting projects to doing projects while you're really learning and helping the organisation to grow and to make yourself obsolete in some way my joke is that we creep away around the back door we start off quite big and quite instrumental and their strategy and the initial training in projects but ultimately that humbleness around creeping away to not be utilised anymore I think that is an immensely important mindset for consultancies going forward yeah and if we manage to actually achieve that we should be really proud of ourselves because it would mean that everybody has adopted their design mindset right? I think so yeah but I think what's interesting though again about this concept of redundancy that can scare people in terms of an agency construct is that there are new problems and new challenges of tomorrow and I think what consultancies need to be able to do is to be able to pivot and move into those new spaces so we should be exploring those now on behalf of our clients who are just at the start you've got fantastic organisations like projectsbyif.everyone who are looking at the future of the internet or user rights data, how information and data is handled and that's sometimes a secondary thing to organisations going on this new journey of design so we can be crafting the knowledge in that space on behalf of our future clients and helping them with that side when it comes to designing in the future really quite complex services I think you're absolutely right and at the same time I also see that there is still so much work to do there are so many organisations especially the smaller SME organisations who haven't touched upon the idea of service design yet that we still have a lot of work to do in that space we won't be out of a job that soon at least not from my perspective and I think what you've said is vitally important is not to forget that I actually have to remind myself sometimes because I like to run away with what's the next big thing and where should we be going and that's my job right that's my job at Snoop anyway is to be trying to take us in the right direction but I meet so many people on a daily basis who are really at the start of their journey and so we have to remember that there's a lot of work to be done and I think for me I said this at the SDN conference but working with guys like Court County Council shows the absolute need particularly in the local government space for this which actually has the ability in a UK construct anyway to make some of the changes happen that we can't currently make at the government level because of certain political things going on right now so I think there's a huge amount of work to be done and be shared amongst everyone You already touched upon the third topic a little bit so let's move into this one and I think you mentioned it in the first topic because it was how can the design can be embedded in front line and the third topic is called front line and system change So let's say we're lucky dipping again okay what if okay what if what if front line staff were in charge of changing the system what does that mean? I'm hugely fascinated by this topic again mostly because of my background and having the very early start in my career working with frontline careers advisors skill development officers people working right at the front line so it's a real passion of mine because often the tacit knowledge around how a service should and could be designed sits with them they don't always have the freedom and the autonomy maybe even the skills to dream big about what that might look like mostly because they haven't had the autonomy but I always knew there was something here and we ran a programme last year and the year before with the Kelly Chase Foundation in London who exist to fund initiatives and organisations who support people with complex needs and to really drive I guess like a more equal society and help those organisations develop research and initiatives around that and so in collaboration with the point people who led the project we ran a programme called Systems Changes and we ran it with 11 frontline staff members who work in organisations who do support people with complex needs and when I say complex needs just for the audience that can mean that you have a variety of things going on in your life it often makes it very difficult to use services that exist because of the way they tend to box people so if you are homeless and you have a drug addiction issue you might be just having left prison you could have relationship issues you could have one, two, three, four a whole number of issues that stop you in your life from living a really fulfilled and happy equal life so we ran this programme with this group of staff some design and service design skills basics and journey mapping prototyping we taught them about systems thinking so looking at more ways to map and visually understand politics, cultural barriers things that exist in a system around the services that they run and we taught them a lot of actually individual things around unconscious bias around how they label people in society and the results were really phenomenal what happened? phenomenal so quite a lot of them I call them like hackers of the system one of them created a new product that helps both staff at the front line and people with complex needs navigating the benefits system with very simple journey maps so you can understand how many minutes you have on the phone until it cuts out what to say on the phone at certain points to make sure that you get put through to the next part of the benefits process and that could be and is hugely vital I think for people so Sarah, I think a lot of people who are watching or listening this episode can empathise with this but I think the big difficulty is it's not really hard to find front line staff who have ideas about how service can be improved the real hard part is I think creating the context or the conditions in which they are able to execute on that to make those ideas happen so why do you think in your example why did it work? I think it worked because we set up the buy-in in the first place from their senior leaders so anyone who yeah what did you do? anyone who came on the program we made sure that the senior leaders actually signed off their involvement that they were fully understanding of the program that they were involved at several points throughout and we taught kind of basic stuff that goes around the design stuff around the presentation skills, communication skills to make sure that those guys could take the things that we're working on back to a board level and show the value of them so we had a few of the staff actually be working because they're in a charity context with their boards and they convinced to sign off new programs of work actually on how they should be moving forwards and in fact one guy last year created a whole new arm of the organization that he now leads up so for me it's about, as you said Mark I think people really understand it's easy to get ideas from people but you then need to look at the more the construction of the right vehicles within an organization in which to enable that thinking about that from the get go really. You sort of have to have someone who understands that from a sort of meta level in the organization I guess right? Yeah completely or help that person who is at the front line and if I'm being very stereotyped about this doesn't have a lot of autonomy to find the people who have the power to make the changes to allow them to do it and so whether it's like you said easy to come up with ideas but very hard to implement them so you've got to really work on helping them understand where and how they can make that idea come to life and that's actually more of the work than it is the design of the thing that they want to happen Exactly Sarah our time is flying but I'm not sure if that's correct English but anyway it's your opportunity to ask the people who are listening and watching this episode a question so what is on your mind what would you like to ask us? The community so I would like to find out if you work inside an organization and you're using design how are you doing it and what has been the commitment or buy-in to that and how are you being measured I'd love to know how you're being measured particularly on the inside of organizations when it comes to an investment in design that's really an interesting topic I have a whole course on investing and selling the value of service design so that's I'm also interested in that leave your comments down below and it's especially for people who are working on the inside because from the agency consultancy perspective we sort of get that Yeah completely I think agencies have done a fantastic job of helping build the service design industry really from the get go and we have to be really good at selling right that's our job and building these processes around it but I'm interested when it gets messy on the inside Yeah the evangelist and the pioneers who take you know for instance we talked a lot about government you have to have some sort of a special mentality to start doing service design within our public sector right you have to have patience and that's a different attitude compared to an agency Yeah completely I think most people will be aware that maybe even quite honestly the remuneration in different kind of roles in comparison to government and maybe private industry is quite different so you have to it's not about money for people it's really about the commitment to want to make people's lives better and I think from my friends and colleagues that work across government I couldn't speak more highly of all of them who are on that journey seeking to do that Sarah Thanks for your time thanks for sharing your ideas the topics I think they are super relevant I hope a lot of people will comment on them and watch the episode so what is your biggest takeaway from this talk with Sarah share your thoughts and ideas down below in the comments and remember more people like you are watching these episodes in your comment might just be the creative spark someone needed if you'd like to learn more check out some of the best episodes or head over to the service design show university at learn.servicedesignshow.com where you'll find courses by leading service design experts that dig deeper into the topics we talk about on the show I'll see you in two weeks time with a brand new episode thanks for watching and I'll see you then


Hello, Tess. So yeah, this is the build process panel, which thematically is all about how do we take our source code in whatever form it may be, and transpile, preprocess, minify, optimize, et cetera, until it arrives in its final form. So my name's Ben Vinegar. I'm a Lead Fine Engineer at Discuss. I also wrote a book called The Prior JavaScript. It's pretty terrible. I have five wonderful panelists with me. First, there's Kyle Simpson. Who you may know is the author of LabJS. He's also an author. He's writing a book called You Don't Know JS. Nick Fisher, who works at SoundCloud, and he designs and implements a lot of the build systems.  Adi Asmani, who develops Todo MVC and Yeoman, which is a scaffolding tool, working with Grunt. And he also works on Chrome Dev Tools. And then Sebastian Golasz, who works for Deutsche Telekom. I practiced pronouncing that for a while, working on a product there that also uses older traditional build tools, like if older's the right word, but with Maven combined with Grunt and some clients and stuff. And then lastly, I have Gareth Rushgrove, who works for the UK government, working on a big project that involves modernizing a whole bunch of UK government websites and bring them into the modern era. And with that said, Gareth is just going to start us off with a quick presentation. Slides up. Do I have to do anything? Yeah. Ooh. OK. Your build process needs you, because it's probably not as good as it could be. There it is. But what is a build process? I think what we're talking about really is it's a way of sharing common actions as much as anything else. If it's just you doing something, well, and you're just doing it once, that's not really a build process. But actually storing it as something that you can come back to, or more commonly, storing it as something that your team can come back to is really important.  If I ask someone to do something over and over again, they'll probably do it subtly different. A build process is always about standardizing those repetitive tasks. And some of that's to do with the fact that words can mean different things to different people. If I say, oh, can you minimize this bit of JavaScript for me, people will do it differently. And that's probably no good in an environment where you're trying to work together. You end up with different results. Someone might take longer. That's no good. We need to standardize. But your build process is software. And certainly for some people, people come to certainly front-end engineering, front-end web development from lots of different paths. And not all of them will think of themselves as software developers.   Live with it. But what are we building? What are the software types of things that we're putting into our build process? And Ben mentioned a few things that will be common to lots of people in the room, sort of CSS preprocessing, templating, Kyle, bundling, minification, linting, testing, optimization, transpiling. There's lots of things we're doing with our code. And there's lots of tools we're using. Two of the common ones at the moment, certainly in the front-end space, appear to be sort of like Gulp and Grunt. Grunt, this was a few days ago, but I bet it's about the same today. Maybe it's less today because we're all in this room or watching on the video. Like 30,000 installs of this every day, that sounds quite a lot. That's a lot of interest. That's a lot of people. There's 2,500 Grunt plugins. And I'll come back to why that might not be great in a moment. There's actually 450 Gulp plugins. And that's a tool that's not being around anywhere near as long. But I said, I'll come back to why that might not be good in a moment. Contrib.js is a Grunt plugin. And there's one for Gulp, brilliant. And there's Grunt Coffee and Gulp Coffee. And there's Broccoli Coffee as well. And at some point, and there definitely will be someone in this room, someone watching this, who's building another one and hoping someone comes along and builds another one, Dash Coffee and JSN and everything else. And we know there's 2,500 Grunt plugins. Do we want 2,500 Gulp ones and Broccoli ones and everything else? And it's not just about the sort of, I think there's probably a lot of front-end people in the room. There's probably not like people writing JavaScript, writing CSS, writing HTML most of their time. Is that fair to say? Any purpose person going, I'm basically just a Java programmer? That's part of how we do that. But we're all working in environments where there probably is a back-end that might not be written in JavaScript. Maybe you're using Node. Maybe you're not. Maybe it's Ruby. Maybe it's Python. Maybe it's C sharp. It doesn't matter. There's a lot of other things going on around you. They also have build processes. And there's loads of build tools, whether it's Maikar and Maik, Maven, NAM, SPD. There's loads of these. There's a bit of a hit bottom that says, two points for each tool, minus five if you liked using Maven. Ultimately, building software isn't new. It's happening all over the place. And having standardizing on things, standardizing things in silos probably isn't enough. Even when it comes to sort of typical tasks around front-end engineering, a lot of those have plugins or projects related to other build tools that are doing it. Whether that's sort of multiple versions of things like Django static compiler or compressor versus sprockets in Rails versus aesthetic in PHP. There's this spiraling mass of all these things doing fundamentally the same jobs. And really sort of everything all is new again. Building software is not new. It's maybe new to, these tools are new, Grant and Gulp. There's a lot of interest around sort of programming in JavaScript at the moment. There's a lot of new tools coming around, but this isn't fundamentally a new activity. And some of the same mistakes have been made. Some of the learnings have not been taken forward. Maik is older than you probably. I wrote this before turning up. I still think that's broadly true. Unless you're 37, Maik is older than you. There's a few people here who probably look older than 37, but I reckon.  Maik is a build tool. If you haven't seen it, it looks like this. If you're thinking, wait a minute, where's all the rest of the code? You can think, well, maybe you should be using Maik rather than Grant. And do you know how many Maik plugins there are? I don't think there are any. That's probably gonna be completely untrue. But basically there aren't really Maik plugins. There aren't really plugins for LS as a Unix command tool. The reason is because Unix pipes are amazing. Or the concept of simply chaining things together by sending information between them. So LS doesn't have a grep plugin or a sort plugin. And it's just about Unix command line tools being able to be chained together. It doesn't matter that these things could be written in different languages by different people at different times. We don't have to customize them all via plugin models. And I think sort of, actually I don't do a lot of front-end stuff. I haven't done it for quite a while. So actually I did a whole bunch of research into sort of like what people were doing to be on this panel. And I thought, as a community, it seems that there's a lot of effort reinventing the wheel. And this isn't just true for this community. That's true of basically programmers, myself included. But we invariably invent things, like reinvent things in our language of choice. And sometimes in our tool of choice. But the thing we often miss is that's our language and tool of choice at the moment. And that probably changes over time. And so anything that we can do to minimize that is probably a good thing to think about. Because we can make things better. And ultimately things are better now than they were before. They're like having tools is good. This is not about saying, oh, we shouldn't have done any of that. Like throw it all away. It's about how can we make it a lot more sustainable? How can we learn from maybe like 20 odd years, 30 odd years of other programming communities build processes? So what is the most valuable unit of sharing? Is it a plug-in? How can we build community consensus and like avoid the plug-in apocalypse? I like that. I think there's a genuine problem there. Can we share entire pipelines as well as tools? And it's fine sharing the individual bits, but actually we probably then all take a collection of things together and string it together to do the same thing. And actually can we share the pipeline? And is that a better unit of sharing? And importantly, how do we break down some of these artificial programming language silos? Because even if you're thinking, well actually my career is going to be all about front-end engineering, it's all going to be about JavaScript and CSS and HTML. And they're probably going to change, they're going to evolve, they're going to get better, the tools around it's going to get better. But that's what I'm going to do. You probably do it in a context where other people around you are writing different programming languages. And how do we mix it? So there's not that culture class. There's not that us versus them. How do we bring these things together? They're just some of the things that were in my head and some of the things that I sort of care about. The panelists might violently disagree with some of that. So with that, we can go onto the panel. So thanks, Gareth. I think that was a pretty good way to start us off. There's a question I'm looking for. Oh, God. Is that kind of browser thing that's been moved around? Oh, boy. I'm going to ask on Cornell Lasinski. And also, I just want to say, I feel that we butchered your question slightly. And if you would like to go original with this, please do so. So is eliminating a need for a build process a goal of web standards? For example, should CSS adopt all the features of CSS preprocessors, or should it avoid duplicating them? So one of the really nice things about the extensible web manifesto has been the community starts to iterate on features in languages like JavaScript and tools like JavaScript and so on. And once we reach a nice consensus there, we can then go and move on to standardizing those features. So in the case of CSS and preprocessors, we've already started to see things like variables actually land and go from things like SAS and less directly into CSS. The same thing is being done with mixins. I think that it's perhaps not necessarily the browser's responsibility to provide hooks into your build process like a preprocessed step or a post-processed step. That seems to be something that would be better left up to additional tools or something on the server side. But I think that we currently have a good system in place for actually landing things that the community is doing and finding useful patterns directly inside native primitives. And I'd like to see us continue doing that. So I want to jump in, because they asked me to be on the panel so that I could disagree with everyone. So I actually think it's a terrible idea to standardize all of these things into CSS and into HTML and JavaScript. For example, I think it would be an awful world if the browser had a transpiler for every one of the 1,000 languages that are out there. There are things that belong in our tool sets. There are things that belong in our technology, and there are things that belong in a build process. And I draw a very distinct line between them. So transpiling, a lot of things that we see in preprocessors are things that I think aren't necessarily great to be in the CSS language. They're things that tools could do for you. So I don't think it's a good idea at all to go down that sort of slippery slope of saying, anything that I can dream up should just drop into a standard. I think build processes are there for a reason, and I don't see them going away any day. If anyone's got a way of just dreaming stuff up and dropping it into a standards process, though, I'd like to hear about it. That would be awesome. I think fundamentally, the friction around standardizing things is it takes time and it's hard for good reason. So actually, I think the answer is yes. But realistically, the rate that that happens is slow for good reasons. Until we can broadly all agree on something, then it's not going to get standardized. And we're definitely not going to broadly agree on everything at any time soon. So therefore, it's the stuff that we can fight about that goes in our different build processes. I kind of agree with Kyle here as well, that I think one of the real benefits and the reason that JavaScript and CSS got to where it is now is because it didn't do that ever. It is a very bare bones language in JavaScript that has let all of us then come up with these new tools and these new things to build upon a very basic level. And I think that if we decide to do that, say, 10 years ago, we might have a very different language today. So I just sort of like tack on to this, which is that historically, have we even done a good job of when we take features from other languages and bring them into JavaScript or CSS? People talk to me a lot about we shouldn't even be using jQuery or we should be doing straight DOM, but I find that those API methods are still pretty verbose and they're not very fun to use. So if we went along the path of bringing a lot of these, let's say less than SAS features into CSS, would we even get it right? Would it be fun to work with? I think it's OK for these tools to inform standards, but I think we should draw a line and say not just because somebody can put something into a build process doesn't mean that it will ever belong in a standard. So there's plenty of good examples for better or worse that CoffeeScript informed ES6. And I think those, you know, I don't like all of them, but that's good that we were able to inform that. But I don't think that it would be a good idea for CoffeeScript to natively start being in the browser. I think that's a build step. So I think the TLDR of that is it looks like it's probably not the best idea for everything that's possible inside a build process today to be baked into the browser. We're always going to fundamentally differ when it comes to our tools. And there are going to be some patterns that it makes sense to eventually land natively. But on the whole, if we can do something outside of that process, let's keep rolling with that. And also, in my opinion, the good part of using a tool and a build process, using processing before it is in the browser, is like, if it doesn't make sense, you can throw it away. If it's once it's been in the browser, it's there forever, period. And that's a huge problem. That's also why standards are slow in the common sense. But it's the right thing. There was also a second part to Cornell's question, the original question. I don't know that you touched on it exactly. I was hoping that he would. But it was about, should the idea of preprocessing itself be a standards feature? Like, we are basically in agreement that it seems like most of our code is being taken from one source into another. Is there an idea of having a preprocessed step versus a runtime step? I'm looking for a nod from you. Does this seem to have a capture of that? So why not always thinking where CSS should be optimized for being preprocessed? Whether it should have syntax or features that are not for humans to type manually, but for preprocessors to generate, for example. Like, $9 in JavaScript. Any comments on that?  And I think that's a better way to go. So again, what I said was, there's several things that we've been informed by LessonSas that do belong in the CSS language. And I'm glad that we've got tools that have sort of standardized on what those things are. Like, for instance, being able to drop in a value, or for instance, being able to nest a rule, or something like that. But there's a whole bunch of other stuff that I think should be externalized. So I think we can draw those distinct lines. And I think the tools can standardize on the stuff that is smart. But that's obviously a gray area. I mean, it's hard for any one person to say, here's where the line goes. So the community, I think, needs to be more responsible about not just looking at the new shiny thing that somebody dreamed up, but saying, well, really, should that actually be adopted, or should that stay in sort of the user lane? I think we need, as a community, to be more responsible with that decision. Okay. On that note, I'm going to bring us to our next question. I'm going to call on from the audience Ernesto Jimenez. So the question is, much of the new tools and processes are growing within the Node.js community and depend on the Node stack and NPM. Do you think this dependency might be limited in the future? So let's talk about Node for a moment. So Node has been growing in popularity quite extensively over the last couple of years. It currently has something like 35,000 downloads a day. I think 0.1 was downloaded something like a million times. And so Node's popularity is increasing, which is great. At the same time, you have to remember that the long tail, so not necessarily the people in this room, but people who are still afraid of the command line, people who want to be able to optimize their pages and their apps and so forth, but don't necessarily feel like it's a nice place to go into the command line. They still feel it's really, really scary. It's those people that we actually need to come up with solutions for. And there do exist tools that can help with this stuff. The long tail generally like working with GUIs. And we can tie that stuff back to Node, whether we're using something like Node WebKit or additional tooling. So that they just have to say, well, here's my project or here are the directories I'm working with. Can you just bind these to the different tools that might do pre-processing, post-processing, and so forth? So I don't think that using Node is something that's stopping us. It's just gonna be about improving awareness of how okay it is to use things like Node and the command line when you're actually working. I think coming out of that from a completely different point as well is sort of Node's runtime. Yeah, whether someone's using command line or another tool, it's just something that's actually occurred. For some environments, that is a barrier to entry. They're not going to put Node on their environment. That's fine. That's gonna happen. One thing that is happening though, because I think there's been a lot of interest in the tools that have been built on top of this, people, there's certainly some work around basically embedding a Node runtime in the JVM for environments which is same, seems to be saying like, we're not gonna install this random new tool, but we are happy with running all this JavaScript. So I think, and that becomes a less limiting factor over time, the tools will be able to be run in different places. So to build off of that, I think what it gets to is, I would wholeheartedly say, we should standardize on JavaScript for driving these tools. But Node is the tool right now. It won't be the tool necessarily five years from now or 10 years from now, because Node wasn't the first server-side JavaScript engine and it's certainly not the last. We had one from Netscape in the very early days of JavaScript. It didn't survive Rhino and now Nashor.  So I think to the extent that it's possible for a tool author to build a developer tool, I'm sorry, not a developer tool, a build process tool in JavaScript and try to be as agnostic as possible, try to put as few touch points to the specific host environment as possible. Then we see that five years from now when there's something that supersedes Node, it won't be as hard to convert that tool over. Most of the logic will survive. So I think we should be doing that. So, okay, go ahead. So if we think like five years ago, we didn't have Node and back then we did like build scripts with Ant, this XML Java thingy and maybe put a Rhino jar in there because we only knew JavaScript and so we could script something up that does a little bit on top of it. It was hard to configure and so with the rise of Node, front-end developers who were capable of writing JavaScript and couldn't write some other languages or only sees as an HTML besides. Or didn't want to. Or didn't want to. Well, just had the power to tap into that build process without just learning another language or whatever or another tool. So they're now familiar with the stack and they can embrace like this whole plugin ecosystem or whatever. And I think that's a really good thing.  So, I think everyone seems to be pretty positive on Node but what about this idea that there's a huge dependence on NPM as a package manager and then the NPM repository for which I think it's fair to say there's been some bumpiness too. What are you talking about? Well, bumpiness just in case to contextualize this, like for example, I think a month ago, they changed their certificates, their security certificates without notice. And then I think a lot of people who had dependent on Node, they just couldn't download packages for a day and there was no instructions, there was no communication about what had happened. Just as an example point, it's not the only one. Would anyone wanna touch up on this? Perhaps I'm gonna start with you. I think that's gonna be a problem if you're relying on any third party to host the things that you need for your application. I don't think it's unique to NPM. I think NPM's solving a really good problem right now. But if something were to replace that in the future, then I think that it shouldn't be that difficult to actually transition across to that or even get rid of that all together, like flatten all your dependencies, check that in if it came to that. I'm not suggesting you do that but I don't see that NPM itself is an issue there. Well, NPM is actually, if I understand, isn't it, it's sort of like a protocol that you could theoretically, and I know companies do, spin up their own NPM instances. So we don't necessarily have to think of NPM as the one global universal repository. It can be a way to get your own company internet repository or something like that. So I think that's good, but I would also say Git and GitHub are pretty awesome for that too. So we don't have to discount those as the place that we keep repositories. Google the audience here, I'm sorry, I don't know your name, but do you have a comment on this? Oh, your name's on your badge, well, Jonathan. So we have the issue as well that a lot of these tools are now being stored in GitHub, a GitHub's a company and we're relying a lot on GitHub, so what should be done so we can get just distributed so we can technically use lots of different videos. Yeah, don't use GitHub. Yeah, use Git, not GitHub, use NPM, the protocol, not NPM, the universal repo. But what about the idea that, so I mean, obviously you can spit up your own thing, but NPM is now, it's a private company, right? And if you go to other languages where there's PyPy and there's Gems, those are all actually community efforts with Sponsored, as far as I understand, right? So does that change the landscape at all? No? All right, let's throw it out there. I'm sure it does change the landscape. I would love to hear from Gareth. I would love to hear from Gareth about that when you work with government people, what do they say when the piece of software that you rely on is a 0.1 release and not a 1.0, 2.0, 5.0 release that can be trusted? So the version number thing is nearly red herring. It's like it's an arbitrary string, basically. It's only representing value in the I of the author and so you can just go, well, if someone goes, oh, well, it's got to be one. Like if you tell the author, they might just make it one. But there is a, and ultimately, different organizations will have different, sort of like, like risk appetites. And that's true of, like, so I work with the government, yeah, there's going to be banks, there's probably going to be like your new startup. The thing that kills your new startup is probably not a bad dependency from a third party managed service, but it might be something that has an impact on a bank because someone tries to compromise that service and come back to you. It's a really hard problem and it's not specific to JavaScript, specific third party package math services, which broadly, like, sort of having one per language was a stupid idea. It's too late to fix it. So the next new language that comes around will probably have an NPM or a Ruby gems. It's a bit of a shame. The package management systems within operating systems sort of solve a lot of the problems and people forget about the problems they're solving. CPAN for Perl does loads of, like, really interesting stuff that no one's recreated in the last 10 years. You guys, we're gonna, we're gonna, oh. One addition. I think one thing that will help us with at least the security concerns about using NPM is when NPM adopts something like Maven does with package signing and stuff like this, so we can assure our clients that this thing is really the thing that we said it's gonna be there and not something different because someone hijacked it or something. So it solves the sort of mental issue. It doesn't solve the fact that someone might have compromised the person who was uploading it in the first place. In general, isn't it, I find it always fascinating. Guys, sorry, I'm getting, I'm getting thrashed to get to the new topic. Okay, cool. So we could go to the audience again. And I think this is a pretty exciting question. Oh, I guess I'm not going to the audience. I guess I'm supposed to ask Kyle Simpson to ask a question. Like I said, they put me on the panel so that I could stir things up. So I get the pleasure of asking this question. There's many browser wars going on right now between grunt and gulp.  But there's several other would-be congenders. And that sort of betrays this idea that maybe there is one right build tool to rule them all. So the question is, is that a realistic idea that we're striving towards one great build tool that we need to find? Or is it just idealistic? And is it harmful fragmentation or useful experimentation? I think that traditionally having multiple tools is a good thing because it drives innovation. And I don't think that that's a bad thing in this community. Build tooling on the front end is still very young and it's somewhat in its infancy. So I don't think it's necessarily a bad thing. One thing I would like to see is us sort of standardizing on perhaps a task specification. I know that there's been some effort from different build tools to standardize on the no task spec, which talks about things like having a single way to handle records or logging or notifications and so forth. I think that that could actually help us avoid having to sort of have this sort of crazy wheel of re-implementing things all the time. But I know it has its own challenges. I have an opinion on the gulp and grunt thing, which is I don't care. I don't use either of them. And I see these tools as useful for certain situations, for certain situations, but they are kind of glue that sticks together interesting things. I think the discussion and browser war type arguments going on, well, I'm not sure if that's really arguing, but arguments going on between these things really distract from why we're even doing a build process in the first place. Like we're doing it to get faster websites, to get better development time and so on. If you use grunt, if you use make, if you use and, I don't care. It's like what we actually do in the build process which is actually important. I would personally like to see less people re-implementing grunt coffee, gulp coffee, whatever, and just have coffee, just use that and hook into it any way you want. So you feel like we should get closer to the grain and just actually call the existing tools rather than writing like wrappers around this. It seems to be interesting. The wrappers are fine, but just recognize that they are just wrappers. The important thing is what it's wrapping and what that actually does and how you can plug these things together is just details. I was going to write up some months ago about, it was kind of tongue in cheek, but it was tasks.js, which boiled down to simply just writing the JavaScript yourself. And while it was funny and sort of interesting from a boilerplate perspective, I think what it does miss a little bit, the reason I write tools and the reason I would make a grunt plugin for my tool is not because that's the only way to use my tool, it's because I'm trying to lower the barrier to entry so that I get bigger market share. I'm trying to make it so there's as little boilerplate as possible to drop my template engine in. Of course, some people, and I might have the same perspective, but some people would say, well, it's okay to raise the barrier a little bit. If you want to use it, you have to know how to use it, call the API, well document the API. So I think that's the reason why plugins exist. Everybody wants to make it so that their tool is the one that blows up and gets 10 million stars on GitHub. Sebastian, you had a comment there.  I mean, in the end, it's a tool and a tool should help us. So if I like Hammer B better in my hand than Hammer A, then I use Hammer B because it's better for me. And the same is it with grunt and gulp and brokely and fast or whatever.  So you can write it because it feels more familiar. And if you're a front-end developer, most of them like grunt more because it's like this declarative approach where you only have to configure things. And I think it comes down to use the right tool for the job.  Just first over here and then Remy. Well, my friend here is actually gonna be out of use. Oh, oh, sorry. Yeah, so disclaimer, unfortunately, I'm one of these people who has also developed another build tool for Hammer. So I agree with everything we've said. And I think the idea of having interop between plugins is great. One thing to remember is that these tools are there to make it really easy for people. We want people who are scared by the command line to be able to do the right thing by default without having to worry about configuring crazy parts everywhere. So to me, the real question is what is the good baseline for these tasks that would work in different tools so that it does the right things? And just to throw a few examples is should it be able to produce source maps correctly for everything by default? Should it be able to rebuild partially so you don't have to rebuild all your things every time? And all these things I think need to feed into what is the common format for these big tools? I think one of the really big challenges with coming up with a spec for build processes and that task spec is that it's difficult to create something that is flexible enough to also match the architectures of these different tools so that they can work behind the scenes and do what they need to do without necessarily feeling overly constrained. And unfortunately, so the node task spec idea that I talked about earlier, that's actually something that is currently on hold because none of the build tools could actually reach agreement on how they should approach this problem. It's really, really difficult. I'm hoping that later on in the year they'll come back to it and think that it's something worth value. We talk about something like, oh, it's good to have multiple tools because that breeds innovation. Don't think you can't get locked in to an open source tool because you can. It's not just commercial stuff. We're talking about lock-in. You get yourself locked in by something by saying like, you know what, the barriers to moving from this tool is so great, I'm not gonna do it. At which point you benefit not one bit from the innovation coming from all the tools. Okay, can I get a quick comment from the audience here from Remy Sharpe? Yes, I mean, I don't personally use build tools at the moment. There's one step, but the thing is, jQuery was the tool that made working with JavaScript really stupid simple for a large amount of people and suddenly they were able to write JavaScript without writing JavaScript. And these big build tools have given me a way of just adding minification and getting that done whereas before I wouldn't have done it and many other people were doing it. It's all about getting locked in. I don't think it matters at this point. The build, like getting hold of build tools at this point was so new for this community. If we get locked into grunt for a few years and eventually their stabilization in five years time, then that's a huge step forward compared to just not doing it at all and just delivering massive images out of wire, uncompressed images, we're still at that very, I think we're still at that very early days of when jQuery was kind of really spinning up the charts with us. I agree with that. I feel like this build tool conversation sometimes, it skips over the fact that we don't talk enough about what's inside our build process. We should be caring more about image optimization and image compression. That's the thing, images are the thing that are slowing down the web today. And we need to get more people caring about those problems and spend more time talking about how we can actually speed up our pages in less time, perhaps, on arguing why you should be using gulp versus grunt. I mean, there's still fantastic tools that I think Sebastian said earlier, people who are more familiar with note are perhaps gonna use gulp and people who aren't are just gonna use grunt and that seems to be working. I know. I'm gonna cut you guys off because actually the next question, I think it goes into just what I was touching on. I'm looking for, from the audience, Peter Mueller. I will have to read this as well because it's been changed a bit. Most build scripts, including those generated by scaffolding, are a chain of several discrete steps. Do we even need the complexity of having control of every one of these steps? Or should we instead have an opinion at a build chain that just gets us to the end point that we're interested in? I like to see what's going on. Yeah, so like from my experience, like I've built an opinion at a tool chain for our own build system that we needed. And I'm really happy with it. There's been a lot of work put into it, obviously, but I think in the end, you actually get, like if you really want to get total performance out of your build process and on terms of how fast it runs or anything like that, but in terms of what actually executes at the end of your build process, then I think that's definitely a very smart way to go. And you definitely don't need any particular tools like Grunt or Gulp to get you there. Kyle had a comment at the start. Yeah, so I think going back to the UNIX philosophy, which certainly informs a lot of what we're doing, it says have lots of tiny little tools that can be woven together. And I think that's the more appropriate way of doing this. When you get to the point where you've decided that there is a particular flow through those tools that makes sense for you, you write yourself a bash script so you don't have to repeat it again. And that's all you need. And in the JavaScript world, when you have a set of API calls through these different tools, you just write yourself a little node script that repeats that process over and over. So I don't think we need to worry so much about, oh, there's too many details here. You just wrap a script around it and then you don't have to worry about those details. I think the thing is, you said for me and I write, and I think actually sharing that unit for some people is really valuable. Some people in this room are gonna go like, I'm a really good programmer.   So I just think- But I want the magic from people who are really smart to do it for us. No, I just make a gist. And then I tweet it out. That's my solution to that problem. So one of the things that we try to do with the- Can't you reach the long term if the people- Yeah. Yeah. Yeah. Yeah. Seriously? Distributing really usable software is hard. Packaging that up into a sort of something that is just easily usable off the shelf by someone who does not understand what's going on in the middle is hard work. But like it's valuable. And there's probably two off, like instead of these millions of plugins, there's probably two or three good ways that would be good enough for 80% of the people. So- So one of the things we try doing with Yaman is actually trying to provide people with like opinionated workflows, especially when it comes to things like performance and what we think people should be doing. Because a lot of people don't know exactly what they should be getting in their build process to actually keep their pages fast and so forth or what build tasks they should be using whether using like grunts or gulp. And so there do exist solutions to help you with opinionated stacks for the stuff. But at the end of the day, if you find those too much and too overbearing, you can always just use them for reference, right? In the same way that people use HTML5 boilerplate, just take what you want, delete key-friendly the rest. Just gonna go back to Peter here. Yeah, I'd like to touch on Kyle's point about the Unix philosophy. I love the Unix philosophy, small tools being able to chain them together. The thing is that Unix pipes work with text and webs of files are not text. We would need to be able to pass objects like we can do in PowerShell. Yeah, as well. Because the thing is, some of the things that are really, really difficult to do with the existing build tools, revving files, concatenating files, all that stuff, are things that both grunt and gulp do really badly actually. Because they're based essentially on a continuation of the Unix philosophy or the Matefile philosophy. I touched on earlier, steal things from things outside your community. And one of the things to steal from is PowerShell, because for those that haven't come, that are familiar with sort of like that Unix philosophy of sort of chaining small things together, PowerShell adds basically full objects in between those things and you can do a lot more with that. But I don't think we need that. If you look at, not that it's bad, but I don't think we necessarily always need that. If you look at the flows for JavaScript tooling, parsers, analyzers, transpilers, code generators, and that whole flow and that round trip. If you look at that, they decided we start out with source code and then we move to a tree format. And there's a relatively agreed upon tree format, the AST. We're actually working on a more complete version of that called a concrete syntax tree. That's the thing that moves from tool to tool. And then when you get out is more compiled code. So I don't think that's a big problem. I feel like we've had a little off track. Is there merit to having a, let's say like a plug-in like Grunt Awesome that just does everything and whether now we're getting into the details of chaining and stuff like that. So maybe just to bring it back. Just a comment over here. Why would you do that? Because I think a lot of the things, the unit's idea is to chain other things through sort of in a functional way. You're taking output from one thing into the next thing. But some of the things we do and there's one in Yoavun that is the one that transforms. You can run things. You can take chunks of JavaScript and compile them into different files and it keeps state. So it can do something at the start, go through the whole chain and then refer back to something that happened. And that's the same revision, revving things. You have to have some idea of the state of the whole system to be able to rev things later on and go right. This is what has appeared.  So we always go back to that. I'll just do it in Unix way. But there are some things that just can't be done that way in very well. Any comments on that? Yeah, that's kind of what I was saying. Like this build script that we use has a lot of these things that like at the start we find all the assets and then we have that state that is then used later on. The downside of that is that it means that like you can't really share your tools very easily because it's very specific and bespoke to your application. And I know like one of the themes that's kind of coming here is like sharing and helping people get into the community. But there's the other side which is I want to build the best app that I can for me, which might sound a bit mean, but like that's my job. And I'm pretty sure everyone else here has got a job very similar to that as well. And that you shouldn't forget that. That sometimes you do have to just do something that you can't open source. That's fine. I'm gonna stop there. That seems like a good closing point. Me, me, me. So I'm gonna call the next question. I'm looking to hear from Ian Feather. I'm very embarrassed. Most of the pain in build process occurs at depth iteration. Would it make sense to implement things like sass and copper script as plug-ins for developers removing the need for repetitive build processes or even in the browser itself? So then he's talking about having extensions which are allowing to iterate without having to build a process. Just to jump ahead of this before you comment. This question interested me because what I seem to read a lot about new tools like Gullfin Produce is that the speed of building is actually becoming really important to people. So what if we can just not have that at all? Any comments? I mean, I'm generally, I think we were all in agreement about things like sass and coffee not necessarily belonging in the browser. We agreed on that earlier. But I think that in terms of your iteration workflow, so Gulp is commonly used by people because when you're actually iterating on a project using sass, it's a little bit faster. Whenever you make a change and you want to see that refresh in the browser, you don't necessarily have as much of a delay as you perhaps see with grunt.  I think that we need to look at how we can actually keep our tools lean and fast where possible to improve on that. It feels like it's a software thing. Yeah, it's a software thing. What you're saying is, well, I have a slow build script and I bet those browser people have got some really good coders who can do exactly the same thing faster. And it's like, well, maybe, or you could find someone else who can re-engineer your build process to be faster. Ultimately, you're doing the same job, you're just doing a different place with code. If no one isn't fast enough, write it in C. So it's Sebastian's idea. I mean, I think the thing is we're web people and we're used to hit F5 or control R and refresh and it changes. And not like the Java guys who could grab a coffee while their thing is compiling. And I think we should really embrace that and not build tools that are watching in the background of file system and then doing something for 10 seconds before we can see the change in the browser. That's not the web and I think that's totally heading in the wrong direction. You have SaaS and stuff, okay, but really don't overdo it. Just keep it clean and simple. I think one point here is to consider like your total build separate to your development time. Things like watches can be good or like running a local server that compiles these on the fly and can give you a good enough representation of the production build while you're developing. If your build script takes less than five minutes, that's fine. Above that there's a problem, but less than that I wouldn't care. As long as when you're developing that feedback loop is very short and do that through file watching, serving individual files on the fly. And then if you separate those two ideas, then I don't think you hit this problem. One area that I think definitely just real quick, one area that definitely needs to get better with those tools is the incremental recompile.  So if we could get smarter tools that it could understand, I only need to recompile this one little part of this one little file, that would certainly speed up a lot of that time. I want to get a comment here from Jake Archibald. That's right, middle. People can't decide which mic he's gonna get. Aside from the performance issue, if the browser understands SaaS or CoffeeScript, doesn't that make tooling better? We've got source maps at the moment, but that is just a basic mapping. Wouldn't we get a lot more if the browser actually understood the other language? I think that we... When you say the browser understanding of the languages, I think we need to realize that it's not just about SaaS and coffee, it's about SaaS and less and stylists and other crazy thing that's been created while people are sitting in this room, but we have to define limits about how we can actually go about supporting these things and what we support because if the browser were to support that, that goes back to one of the earlier questions about us having some sort of like a pre-processed step where the browser could perhaps call out to external tools to actually get the job done. Because that's realistically the only way I can see it being done without you baking in support for SaaS like into the browser directly. And it comes with the build process thing as well. It's still build process.  That could be fine. And yeah, getting into the browser is probably easier than getting it to a standard, but it's not as easy as grabbing a plugin or writing some code yourself. So I think there's this barrier to entry there. Yeah, it's not quite the standards thing, but still grabbing the Chrome's OS code and adding that feature and getting it through a process whereby it's fit for everyone else to use. Much higher barrier to entry. Someone earlier said, and I think if there's repeating, as soon as you put something into the browser, now it's gonna move a whole lot slower in terms of change. So I don't think we ought to put SaaS in there until we're really sure that it's pretty much done. And I don't think it is. So I think we need to keep it separate. First comment over here for me. Quick one, when you said like ramping up people, I think the web started and became so big because it was easy to write something put in the browser and see it. And when I see a lot of people tweeting like that people look up to that tell people if you wanna start with web development, go to the command line, get a Ruby gem, do this, do that, do that. It's no wonder we're using new developers to close platforms instead of the web. So could we do a better job in actually promoting power tools only to power users rather than saying start with this? I think so. Sorry, I actually got one more question coming up that I think basically captures this. So I think we're just gonna jump to that also because we're running low on time. Boy, I should have queued this up ahead of time. Oh, boy. Oh, this is over. I swear it was here. Let's start addressing this question while you look it up. Yeah, yeah. It's more like it's looking, finding the person who speaks it. Who's got that question? Let's go to the audience. It's a question about is tooling taking us away from these fundamental building blocks? You do? Yeah. See? Crowd-sourcing. I think that the fastest iteration loop today is probably just sticking directly with HTML, JavaScript, and CSS. Only use these power tools when they're actually gonna be genuinely useful to you. That's I think that that's at the core of what you're saying. And I don't think that we should move away from that. If you're just hacking away on something, there's no reason not to stick with those tools. Where all this other stuff becomes important is when you're trying to develop for like a large system or something that's gonna go out to production. And you wanna make sure that if someone's accessing something on a slow network on a phone that it's actually still fast. Right? So, Adi, you're just gonna... Sorry, go ahead. Also, can you say your name? Because I don't have a problem. Yeah, my name is Lorie. And the question obviously has been rewritten, but it covers my question exactly. As build processes become more and more complex, our source code gets further away from the fundamental building blocks of the web, JavaScript, CSS, and HTML. How does this affect future maintainability and is this a good thing? Yes, it's a good thing. Because we all pick our various levels of abstraction. Some people loved writing in assembly, some people didn't, so we picked a higher level of abstraction. So all of these extra tools and things, when you decide, I say this all the time, source code's not for the computer, it's for the developer. Computer just cares about ones and zeros. So you choose closure script because you like something about that tool and the way that allows you to express your code. And that makes you a better and faster and more efficient developer. So that's a good thing. So to play just devil's advocate for a moment, but what about all the resources that we've put behind HTML and CSS? We have, MDN doesn't have copy script examples. And W3Schools does not have SAS examples. We have this huge base of knowledge and are we getting away from that and is that necessarily bad? I think back in the days, we looked for developers for the web and they must understand HTML, CSS, and JavaScript. And today, we're looking for TypeScript developers, SAS developers and not... Who's looking for TypeScript developers? Yeah, I said, like, when, I'm... Yeah, certainly when we're hiring, we're not. Like, we're looking for... Like, on the programming side, we look for programmers and on the front-end side, we're looking for people with a really good understanding of HTML, CSS, JavaScript, and the fact is, everything else they'll learn. So like, we write a lot of Ruby code and we've hired actually relatively small number of people who were proficient in Ruby to start with. But they were programmers. And you're doing it right, but I've seen job descriptions with lists of tools and it's like, oh, in the end, yeah, you don't need to know all of them, but we just lined them up because they're so popular and we want to attract people to work for us.  This is where you get job descriptions, like 15 years of AngularJS experience. I think to go to what Christian was saying about, like, how scary it is for a new developer. I don't think that should hold us back. I mean, you can still start with, you can still have those tutorials. They're definitely very worthwhile, but JavaScript is where it is now because we didn't let it hold us back. That we did start building upon it and create really amazing things with it. And the more that people do the amazing things, that's even better. So I don't think necessarily having a zero-level entry barrier is a goal. Just want to get an update from Florian. It didn't, I think you're not really addressing my question because what I'm worried about is I'm writing code today and it may be SAS, it may be JavaScript. And in five years' time, I go back to that code and I can't run it anymore because it's not standardized. All I can run is my previously compiled code and the output is... I think that should be a serious consideration before you choose one of those tools. So one of the challenges with choosing... Different organizations as well are going to have a different threshold for that because if in five years' time your startups either been sold at which point you don't care or it's gone bust and you don't care, actually probably doing what they're optimizing for right now is massively important. Government stuff, like, yeah, I'm not going to choose something that's not standardized. Adiotto, come on. I mean, I was just going to say that if you're choosing an abstraction, you're almost marrying yourself to it. And you can't expect, you know, you can't expect SAS to necessarily be the thing that people are going to use in five or six years' time from now. You can't expect people to still be using CSS though and probably JavaScript and probably HTML. So sometimes staying closer to the grain is not necessarily a bad idea, but to add to your point, a lot of the time these days people are just trying to build stuff that works now and you need something that's maintainable for right now. And if that makes sense, sure, use these new tools to augment your experience and make it easier for you to develop. But I think that our abstractions are something that they're not going to be around forever. Well, we're out of time, so I think that's a good place to end. Just want to thank all these amazing panelists for their thoughts and opinions. Thank you guys for your time.


What's happening guys? It's Shane here. So this is going to be a little bit of a controversial video. It's probably going to rustle some jimmies here and there, but it really just needs to be made because one of the most overhyped and overrated professions out there, in my opinion, is becoming a medical doctor. And I think that most people that want to become a medical doctor would be much better off going in a different direction. And in this video, I'm going to break down exactly why I think that is. And this video is not meant to make fun of doctors or belittle them in any way. I have a ton of respect for medical doctors. This video is meant to be a warning to people who are bent on becoming a doctor because I see so many young people out there who've got the blinders on. You know, they've got that tunnel vision for becoming an MD. Smash the like button if you've got that 2020 tunnel vision. But for a lot of young people out there, it's like nothing else matters. It's become a doctor or die trying, and they don't even consider any other careers. And I think it's really gotten out of hand. It's gotten to the point where there are YouTubers on the platform right now that are charging people thousands of dollars, sometimes even tens of thousands of dollars just to teach them how to become a doctor. The internet is for smart, established doctors like me. That means people are willing to pay all of this money just to increase their chances of getting into med school. So not only am I going to go over reasons that being a doctor is overrated and it's probably not for most people, but I'm also going to offer you alternatives towards the end of the video. So first things first, I think it's appropriate to ask why is it that so many people want to become a doctor? And if you ask most people this question, they're probably going to give you some sort of response like, I want to help people out. But when you ask them the follow-up question of why not try to become a nurse practitioner or a physician's assistant, after all they can write prescriptions and diagnose people just like a doctor, most of them will give you a blank face. And they won't really be able to give you a coherent answer. And if they're being really honest with you and really more than that honest with themselves, a lot of them will say something along the lines of, I'm not really sure why I want to be a doctor, but I've always wanted to be one since a very young age. And if you're watching this video and you find yourself thinking like this, in my opinion, that is a huge red flag that you need to reevaluate your decisions. Now, I've met a ton of people like this and most of them of course won't admit it, not to say that they're lying or anything. A lot of them are just not being truthful with themselves. But there's usually three main reasons why they really want to become a doctor. And by far, the number one reason is because their family pushed them into it from a very young age.  It was the best possible future that they could have. And so for that reason, they wanted to be a doctor ever since they could remember. Yeah, that's it. All right. Now, in my opinion, the second most common reason that a lot of people want to become a doctor is for the status. Now, being a doctor has always been an extremely respected profession. Even hundreds of years ago, it was respected. But in recent times with the onset of TV and different shows, it has been idealized to a whole another level. TV shows have been glamorizing becoming a doctor for the last few decades.  Society puts medical doctors up on a pedestal and in my opinion, they should. But not for the reasons that they do. And later on in this video, I'm going to explain exactly what I mean by that. And then the third most common reason, which I think is the worst out of all of the reasons, the most ridiculous one is people do it for the money. Now, of course, if you just look at the raw figures, you know, medical doctors do get paid quite a bit. It's more than nurse practitioners. It's more than physicians assistants. But it's really not as much as you might think. And later on in the video, I'm going to go over the numbers and explain to you exactly what I mean by that. So let's go over the first reason, which is pressure from family or society. Now, like I said, I think this is the most common reason that people try to become doctors. And I also think this is the one that leads to the most burnout. And the reason for this is because the idealized version of what it's like to be a doctor in your head is so far away from the actual reality of what it's like to be a doctor, that I kind of think weirdly, this causes attention and a lot of stress. And that can really break somebody down and it can lead to burnout. You know, at some point along the process, you realize that being a doctor isn't at all what you imagined it to be. And this could be after you've gotten rejected a few times from med schools and you're starting to consider going to a Caribbean school.  Or maybe it's when you're in residency and you're working 80 hours a week and you haven't slept in two days and life is just generally pretty bland because you don't really have a life. Or maybe it's when you start working your half a million dollars in debt and you realize is this it? Now, if you're lucky this happens earlier on in the process before you've done a lot of damage and you've gotten to the point where you can't really go back. But unfortunately, a lot of people don't get lucky and they find themselves in a situation where they're trapped and they can't get out. This is why half the time when you see a doctor, they hardly make eye contact with you. I want to reward you with five minutes of uninterrupted eye contact. They seem really tired and not very passionate about their job and they also seem like they haven't slept in days. Yeah, probably got restless. And this isn't to even mention the high rates of suicide and depression that you see among doctors. In fact, this profession not only has the highest suicide rate out of any profession in the United States, but also the rest of the world as well. A 2018 study estimated that the suicide rate was between two and five times as high as the rate of the general population. We're not talking percentages here, we're talking magnitudes. So doing something because your family wants you to or because society wants you to is not a good reason to do it. And it's so much better to be honest with yourself now rather than later. And it's worth it for you to put in the time to really research this rather than committing to something and then doing the research later on. Now, like I said before, the second big reason in my opinion that people become doctors is because of the status and respect. And the first thing you need to realize here is that becoming a doctor takes an incredible amount of sacrifice, not only from you, but also from your family and friends. We're talking 60 to 80 hour weeks, sometimes more high stress level, tons of responsibility. Every single thing you do is scrutinized. So you have to always be laser focused while you're at work, patients being extremely angry at you all the time, a lot of negativity from not only patients, but sometimes some of the other people you work with. And on top of all that, you have to deal with a lot of politics and red tape that you probably shouldn't have to deal with. And basically what I mean by that is you can't just do your job. You have to document every little thing that you do because of insurance issues or something along those lines.  Literally one of the worst days they've ever had. And so there's a very good chance they're not going to be treating you very well just because they're in a bad mood. They might be a great person 99% of the time, but on that particular day, they might treat you really badly. You'll get scrutinized by a lot of the other people you work with. You're constantly going to be under a microscope. And then on top of that, your family, your friends, your significant other, a lot of them aren't even going to get to see you that often. So this idea that you're going to be some high status person really isn't as great as it seems. And really, I think that intrinsic satisfaction and fulfillment from your work is going to be a lot more important than thinking about the way people view you. Now, a lot of people will look up to you as a doctor and they should because it's one of the most important and valuable jobs out there, but really not everyone can or should try to be one. But overall, with great power comes great responsibility. Yeah, of course it is. And this is a very overrated perk of being a doctor. Now, the third reason for becoming a doctor is like I said before, probably the silliest one and that is because it pays really well. Now people have this perception that doctors make a lot of money because if you look at their salary, it looks pretty good, but there's so much more that goes into this that people just don't think about. So first, let's talk about the insane amount of debt that you have to take on. The average doctor will take out over $200,000 in student loan debt. And a lot of this debt is what's known as grad plus loans, which if you know anything about that, they compound at 6% to 7% interest and they start compounding right away, right when you take them out, not like undergrad loans, which start compounding when you graduate or oftentimes years after you graduate. So for instance, getting an engineering degree, the interest on that would be somewhere around 3% to 4% and it wouldn't start compounding until months after you graduated. Now, there are so many different factors to consider here and it would take an entire video just to break down this one thing, but one of my favorite channels on this subject on YouTube is Med School Insiders.  And they found that a medical doctor won't catch up in net worth with an engineer until the mid to late 40s. Now, there are a lot of assumptions on this spreadsheet, I admit it's really hard to factor in every little thing. But honestly, I think he was pretty nice to doctors because he didn't even include the 7% grad plus loans and the compounding interest that starts right away while you're still in school. And this causes a lot of doctors to go half a million dollars in debt before they even start making money. He also didn't include the medical malpractice insurance that a lot of doctors have to buy. So an extreme example of this would be OB-Gynes, which have to pay somewhere around $85,000 to $200,000 a year in medical malpractice insurance. Another example of this would be surgeons, which generally have to pay $30,000 to $50,000 a year, which is still a lot of money. Now, obviously, you're going to make more depending on which specialty you choose. For instance, anesthesiologists are going to make a lot more than family doctors. But overall, I think you get the point here, doctors don't make nearly as much as you think they do. And this is not a reason to go into medicine. Now, there are other reasons to not go into medicine that don't fall under the previous three categories, but they're still just as important. The first of which is you can't really switch specialties. So once you choose a specialty, you're pretty much stuck there. And you can compare this to other medical professions such as physician's assistant, for instance, where it's actually pretty easy to switch specialties. So you can kind of bounce around to different specialties, work there for a year, or maybe just six months. And then eventually you'll land on one that you really like. And then you can just stay there for as long as you want. Whereas with medicine, you have to get it right on the first try. The second thing, and I kind of went over this a little bit, but there's really no such thing as a work life balance when it comes to being a medical doctor. You pretty much have to be 100% dedicated to your job, and you can't really pursue that many other interests outside of being an MD. So for instance, let's say you got interested in entrepreneurship, you probably just simply would not have enough time to start a business on the side, because you really just have to be focused on your work. As a doctor, there's always something that you have to be doing, even if there's no patients to take care of, there's always studies that you need to be reading up on. So you stay, you know, current with all of the latest literature, and you're giving the patients the best possible treatment. There's literally always something that you have to be doing at all times. And the other thing that's not mentioned is getting into not only universities, but also getting into residencies is really time consuming, difficult, and expensive. For a lot of people, they have to apply several times in a row. A lot of people don't get in on the first or even the second year. And each time it's going to cost you probably tens of thousands of dollars for the travel expenses, the applications, having to take all these different tests, etc. And I have personally seen several people that are, you know, close friends of mine, people I was really close to, that got rejected year after year after year. And it's just heartbreaking to see this. One of them got rejected four years in a row, and then on the fifth time they finally got in. The other one got rejected four years in a row, and they just straight up gave up. Just think of the opportunity cost and what they could have done in those four years with, let's say, $10,000 each year. You could have traveled the world. You could have gotten an entirely new degree. There's so much that they could have done in those four years that they weren't able to do because they were spending all of that time applying to med schools. Then once you get into med school, everybody in med school is the smartest person from their high school. You're going to be competing against the best of the best for the residencies that lead to better jobs.  What are you talking about? Who's getting negative? Of course, this is a very important profession. And there are certain types of people that should go into the medical field and become medical doctors. And so I'm going to go over a few reasons why you should be a medical doctor. Number one on this list is going to be that you're an A type personality. And I think that, you know, this opinion is going to be a little bit controversial, but almost any other profession that you can think of, you can get away, you know, not being an A type personality, but being a medical doctor is the exception. And you see so many people applying to medical school that basically went through undergrad and they were so smart that they just procrastinate until the last moment and they only study at the last moment and they're able to get by an undergrad doing that. But the problem is, is when they get to med school, that's simply not an option.  Number two on the list is that you've done your research. So you've done tons of shadowing. You've made sure that you're not too emotional about it. You're making logical decisions. You spent a ton of time weighing the pros and the cons of becoming a doctor. You've done a lot of research on which specialties you're thinking about going into. And you have a solid plan before going to medical school. Number three on the list doesn't really have a word for it, but I'm just going to call it the stick with it factor. And what I mean by this is you're not only a hard worker, smart, you're an A type personality, but you're also the type of person that can really stick with decisions that you make. Because like I said, you can only choose your specialty once and once you choose it, you have to stick with it for a long time and you're going to have to give up and sacrifice a lot of other things in your life.  If you're the type of person that hates people, then being a medical doctor is not for you. You are going to be absolutely miserable because you cannot be a medical doctor without communicating not only with other healthcare professionals, nurses, pharmacists, et cetera, but also with patients. Now, number five on the list is that you have a deep desire to be the best in the world at whatever specialty you choose. And this means that you're always going to be on the cutting edge so that you can give your patients the best possible treatment.  Now, like I promised at the beginning of the video, I'm going to include two other careers that in my opinion are really good alternatives to becoming a doctor that have most of the upsides as well as very few of the downsides. And these careers are going to be physician's assistant and nurse practitioner. So just like a doctor, you get to help people, you get to make a difference, you can prescribe, you can diagnose, but you also get to keep your work-life balance. You can graduate and start working at 24 years old sometimes even sooner if you go an accelerated route, whereas doctors are grinding all through the best years of their life and a lot of them don't start making money until their mid-30s. There's also not nearly as much debt involved in the debt that you do accumulate. You can start paying it off right away so that you can actually enjoy the best years of your life. You also aren't stuck in one specialty like a doctor. Maybe you start an emergency medicine, you realize it's not for you, and you find that dermatology is your life calling. It's relatively easy to switch as a PA or a nurse practitioner compared to a medical doctor, and I think the importance of this flexibility can't be overstated enough. The fact that you have the freedom to switch specialties is really awesome. And physician's assistants and nurse practitioners have some of the highest rates of job satisfaction out of all of the medical professions. And they both have an insane job outlook, which is how much they expect their job to grow in the next 10 years of 26 and 31%. Compare this to the decent but not amazing 7% for medical doctors. And I've talked about this a lot before on my channel, but it's been shown in many different studies that money will make you happy up to a certain point. Some of them say it's like 70,000. Some of it say it's around 90,000. But after it gets to that point, your happiness does not increase at all with making more money. But anyways, I'm thinking about doing a breakdown of nurse practitioner and PA in a separate video. So let me know if that's something you'd be interested in seeing. But overall, make sure to check out my videos right here. I made them just for you. Smash the like button, hit the subscribe button, ring the little notification bell, and then comment down below any ideas you have or any comments you have on the video. Thank you so much for watching and bye for now.