Designing Even Larger (JavaScript) Applications - Malte Ubl | JSConf Hawaii 2020

today I want to talk about designing even larger is actually a sequel to talk I gave a jessica of Australia two years ago and just like that last time I want to kind of ground this talk in our career progression as software engineers I think many of you in the audience would maybe call yourself a senior self

engineer or if you're not there yet you aspire to be one and so the way I would describe what it means to be seen yourself engineer is that if someone comes to me and they say like hey you know I'm out to do this project in this domain that you already filming you with you would say yeah that's actually something I know how to do I don't need to need anyone else's help I'm a senior person I know how to do it and then this was kind of the series of my last remark was going beyond that and with that software engineering lens but

I'm not talking so much about people but still you kind of transcend beyond yourself right it doesn't the only looking at solving problems yourself you're looking at how can i as a software engineer anticipate our others two things and then design api's accordingly so that they are more successful right so I think that is really beyond seniority in this talk today I want to go one level beyond that I want to breach this stage where I can say I can design software such that for

loops of engineers the probability increases that the suffer that they produce is good now there are three key words here first of all large groups of engineers so if you're working to startup or like a three-person company then this talk may seem superfluous boring and extra like not something you care about but I think many of you may be working insurance companies bangs or anything right like wherever you have a bunch of folks and multiple teams and you kind of kinda need to coordinate stuff then I'm talking about probability

there's no security here right you can only try to set things up so they'll probably work but there's no guarantees there's no silver bullets finally I want to talk about good stuff here so this is not a product management all right this talk will not help you write the right program but it will help you write that program good so what I mean is it being maintainable high performance having low buck density being delivered on time that type of

stuff right these qualities that transcend the product aspect of software engineering I want to clarify one more thing I'm gonna say stuff like frameworks software infrastructure other stuff like that all the time I kind of treat them interchangeably what I mean is kind of suffer that we are building that helps other people build better software and what I would like you all to kind of put your mind into like you're the person in your company who's

responsible for kind of defining how people write software and then write the infrastructure the software that they are using to write software and when I say you build a framework but I don't mean that you make your own react or angular right maybe that's actually the right way to do it but it's not necessary right I think whenever you have a larger set of teams you want to kind of standardize how they build applications and that kind of puts a framework around how people buy build applications so that's what I mean again like think about you being the person

who's responsible for this and then this talk is about how you are successful at that job and I'm going to talk about that in three chapters the first one I call understanding the degree of uncertainty then we're going to learn how to solve all known problems and then final are we going to learn about deploying change cool let's dive right in with our friends or in our Heisenberg telling us that this is actually impossible understanding the degree of uncertainty how far are we that what's actually