all right radical Simplicity I'm actually really I by all I see is simp in the middle of this I'm actually really excited about this this website because I really hope that it's speaks to what I feel let's find out as developers we love complexity type one in the chat if this is true you know what I'm already already the article's triggering me I just don't I I just genuinely don't believe this devs don't like complexity I think we I think we Revel in complexity I know that for a long time I loved striving After figuring out having the greatest typescript Auto complete having this having that and I I came to this one day I came to this realization that if I just use a ma a record string to string and not care I'm going to finish the job significantly faster and when I inevitably change it I don't care and it feels good and I just walk away from it and it's great it feels good it it makes me feel great uh we create complexity with Spas view react transpiling typescript Babel webpack pure CSS graph queel Json and uh on the back end with micro protuff Kafka influx DB no squeal databases Kafka mentioned let's go let's go CFA mentioned uh by the way I do think I mean Proto Buffs can be really really great if depending on the environment so just like one little fun fact um my last little one of my last little tasks that Netflix involved a lot of type problems in fact I even wrote an entire um because it started off in a [ __ ] database which was untyped I actually wrote a library called undefined uh uh get hub.com uh there we go this one which would literally takes in a whole a list of Json responses and creates typescript code out of them I know that's it's a it's rather ridiculous but you just if you don't have um since I could I I literally could not figure out how to do this well I actually just created a program that would create types for me because there are so many types there's like 400 separate log messages but the problem is is that we had games in C++ that were emitting a to game runners in go that had an autod do in typescript like how how do you want to share 400 types I mean this makes sense this is like a perfect Proto buff situation right you have a you have a type that is an agnostic kind of language independent specification and then you can use it throughout your entire stack right so I thought Proto was Proto buff was actually a pretty good use case there anyways all right let's keep on going sorry I'm way off the rails here this complexity this complexity is accidental and not in the problem domain this complexity slows us down and makes development tiresome this complexity leads to shallow domains radical Simplicity makes development fast and joyful again I do want to throw one more thing in there when we did this we started with no types no protuff no nothing and we just raw dogged this that's why I wrote that undefined that's why I wrote undefined just to get that thing done because we didn't do anything we actually did approach it with radical Simplicity just get the thing done first and kind of discover the edge cases and as we discovered them then we upgraded our solution into something that makes some sort of sense and so I was really happy with it this complexity needs a solution to manage it which is often kubernetes if there's ever been a project that is used as a means to solve complexity artificially created it's kubernetes ah it's beautiful the amount of people right now press one in the chat if you have more microservices than users on your project right now you don't have feel bad just type one in the chat if you have more microservices than users it's okay you know no no one's upset about it no one's upset about it it ju it just happens which is let's say and you need to run these things and which many microservices and you need many machines which leads to AWS which brings it uh its own complexity now we Define front-end Engineers that write react apps backend Engineers who write rest and graph quel endpoints in operation Engineers that hand hold kubernetes this leads to complex test setups with mocks and local databases Docker images and build pipelines that take tens of minutes to run rather sooner than later development is tied down by a net of complexity this statement alone is incredible we came from something simple that worked to a massive let's see let's see that worked to a massive complex thing in the last two decades 2005 complexity authorization routing models controllers views dependencies client nothing complexity 2021 pre-rendering asset packing API authorization routing models controllers views dependencies virtual Dom authorization routing model views uh apis clients controllers views dependencies Grant we've also we've also got a lot more complex applications right what was just simply not possible in 2005 is now possible in 2021 we also had a bunch of companies that grew up with this that through the you know through literally millions to billions of users had to grow into these more complex kind of stacks and then sell them as the way that all developer should operate but really react these really complex Frameworks that can come from it these server you know like the whole RSC side of things do you really need that for a marketing site like I get that people are selling you that it's the easiest greatest thing in the universe and maybe it is the easiest greatest thing in the universe I'm just saying that your marketing site with like three price tags a basic few sentences trying to sell something a pretty graphic that slides in do you really need all of that yes and factual okay okay I didn't realize that I didn't I I didn't know that you needed all of that just to make a just to make a sense okay hey hey I didn't I didn't realize that okay my bad my bad hey hey I said my bad okay my bad skill issues I get it uh based on the charts Ryan Stout and trick swelling trick swelling uh web applications got tremendously complex over the years I mean granted they've also become just more um more requirements over the years uh it takes a lot of time for doing a simple thing let's see for doing a simple simple thing like adding a field to a form by the way this is a very great call out if it takes more than like 30 minutes to add a field to a form you have to ask yourself many questions uh for example a birthday field to a profile can't take that long it often does what should take minutes takes hours and then things break and then you spend a whole day making your house of cards run again delicately balancing every service and every version of every framework and tool on top of each other's the result of this is that the last thing developers do is writing business logic if you look at what you are doing and count the lines the smallest amount of time is writing real business Logic the ifs in your code but a lot of serialization from databases with squeal into objects into Json over the wire into react store to a UI because you know real talk you know you have your true state is in your DB which means that your server then serves out the state to the client then the client holds on to the state and then actually attempts to merge State updates into these stores to update the UI like this is a very complicated process and almost every single bug I've ever dealt with is in this region you know it's it you're you're like trying to figure out how to actually do the storage and all that they happen from sometimes sometimes you're get list of movies you know is in the wrong order or you you know you sorted it wrong but those fixes are pretty simple it's all like trying to manage this state change from state a to State uh a prime right it's just like that simple change becomes excessively complex PHP solves it PHP solves it because PHP just says you know what no more of that I still to this day I still think front and Masters did a lot of things right because when I click this it loads extremely fast like that was a very fast load up what was that a half second a quarter second it was really really fast but look at this it's not even a spa that was a full page reload but you don't even notice it you go to here you don't even notice it it didn't they didn't need to be they recognize the fact that they don't need something complex and if they just keep it really really really really lean it's just going to work and I I love I I just love that you know that feel of everything where it's just like you click it it works it's fast it's not hard and it's quick don't they use HDMX they they they were exploring using HDMX they're just vanilla JavaScript right and it feels good it's fast you don't need like they realize that they don't need all this stuff and they the thing is is that even the the things that are complicated such as searching like uh what's it called um watch this rebase right look at that I typed in the word rebase okay what's a what's a good one uh re there's no mention of re right here it actually it's like searching through the logs of stuff right it's pretty impressive what they do and it's fast it's quick it feels good hash ad I don't get paid if you sign up it's not an ad I don't I don't get paid transcript index somehow yeah yeah there's some there's some really great stuff there's some really great stuff there but I just I just love that experience because the experience is actually really really good because they didn't go complex data definitions and graphql squeal JavaScript objects and python objects this leads to shallow domains these Technologies departments act under constant pressure from business when you need to spend so much time on ceremonies around Frameworks text acts and serialization there is not a lot of time left to work on business logic so domains are shallow with 90% being data transformation and IO apps are shallow but what we do want is to write deep domains this is actually a really good idea you know what you should do uh you should try to time yourself on how much time you spend on working with the thing as opposed to working on the thing right like how much time do you actually spend solving real problems versus how much time do you spend solving problems around what you have built it would be kind of a fun experiment experiment to like actually rate yourself because I think that if you had like a high amount of time on business logic and a low amount of time on like problems around you doing your stuff I think that that would be a really healthy business and a really unhealthy business is one that has to constantly be fighting against what they've already written uh I just hear it would be fun to maintain a time sheet well yes I mean that part's not fun I do agree that part's not fun I would probably write a program that I could integrate with uh I3 or put something and say like maybe uh roofi or in my dmenu that I could literally just swap back and forth the times and see where I'm at uh but yes I understand I understand I have to do multiple sh yeah time sheets are not fun time sheets are the devil uh I'm just saying for my own person experience it would be neat to like look at how much time like you spend on which one user problem versus your problems yeah all right I don't remember where I was at but I completely agree with everything right here something about we were talking about like time clocks or something so I can't remember so we're just moving on okay I want you to know that this picture right here hurts my soul how many of you have framework code framework code how much of you do this right what is this 802 80% of the time you're spending trying to get your thing set up versus 20% of the time actually writing your application I think that as this time goes smaller I would I'd make the following argument and I think this is a good argument if you want to measure how impactful or radical your app actually is it should be the percentage of uh the percentage of code dedicated to your app versus uh integrating with Frameworks and services if your app is 95% integration with Frameworks and services and 5% to your own code that's actually doing something unique I would say that your application effectively has no value it's just Plumbing anyone can re dude Chad GPT could generate that crap right like that's not that's not even hard okay this is what chat GPT is good at you you literally you are just slow jippy that's all you're Devon is going to take your job okay this is important that's what that's what's going to make you that's what's going to make you money okay this is just this is just ceremony yeah but sometimes you convince a bunch of people to give you money for uh plumbing and they don't know uh any better this is true this is modern VCS because VCS do invest heavily in this kind of crap right uh but if it's just a CR app if it's just a crud app that only integrates with other things I mean I'd be again I think that you'd find I think that your application isn't all that valuable then right it doesn't do anything that's unique right radically simple applications have deep domains and little code in Frameworks I like it what uh what do we build complex system and architect or why do we build complex systems and architectures complex architectures are a surrogate for real problems okay this this is interesting because there are hard problems I like one of the hardest problems I've seen in a long time uh and I've been lightly involved in mostly just like from observational standpoint is uh when I was on when I was doing the Netflix uh TV application we we only have uh left right up and down and enter right like that's the only buttons you truly have technically you could have a back button as well but this is like a this is really all you get on TV so how do you do Focus how does Focus move when you press down where does Focus go right like that's actually a really hard problem you really have to think about how to make this thing happen and then the problem is when you use something like react you have to integrate that entire problem solving into the application into the framework itself which causes an enormous amount of complexity to be added and that's what's currently on television app is an entire Focus system uh manowski distances all that good stuff uh also muddled in and using react which is really really difficult yeah for those that are wondering where the Chris lner interview is notice that I have Chris lner on today queued at 9 p 9:00 a.m. PT all right so let's hear this because we want to be challenged and domains are shallow developers build their own challenges with new works and systems I I I I actually disagree with this part as that's the reason why we I I do agree that we do want to be challenged I think everyone in here agrees with the fact that you want to work on something that is going to make you feel like you're growing as an engineer right anyone going to argue that point I assume every last person wants to work on something that makes them a better engineer that makes them feel like they're learning that makes them feel like they're actually getting something out of life but I disagree that we create problems just for that sake I honestly think that a lot of the complexity that comes from today's architecture is sold on Twitter and conferences I think we largely have a conference driven development because you were told it's the easiest and no self-respecting engineer wouldn't I mean do you really want to use something in which could possibly make it hard to hire right because there's all these Engineers out there right like am I am I right here like how many Engineers are there right now that are looking for a job like probably zero right like what like zero zero Engineers are looking for a job like nobody's looking for a job no one's willing to uh to actually work on something that they don't know so done with that argument it's just such a stupid argument it's such a stupid argument people like if you could if if you could literally be like hey I if I said I have a job right now I would get a thousand applications I could say hey it's HDMX hey it's htx and view hey it's just view hey it's felt hey it's Astro with react I would still get a thousand applications no matter what no matter what I say I would probably get the same thing hire me the problem uh the problem arising are manifold as Rachel Crow writes code runs on people please keep it simple the same goes for components and systems before code runs on a computer it needs to run through uh run in your head if it takes an hour to figure out what's going on well that's an hour that wasn't spent doing something else more useful and interesting I just like this statement generally speaking if you're new to a project things should take time right there's a lot like again if you can just instantaneously be useful I don't know how deep your moat is gosh is that true is that true what I mean by that is hear me out on this one when I was working at worka uh still what I'd consider my hardest most technical job I've ever had uh we had this thing called the viewer and the viewer This would run on an iPad 2o by the way and you could you could touch and you could zoom in you could zoom out and all the equations were in JavaScript and my first bug was something to do with like when dragging this way there's a problem and on day one at my job I got a bug I got a computer and I solved a bug day one and it's because the codebase though a very complicated problem the setup to be able to run little test applications and to be able to fix bugs was super super simple to run the actual whole application was really hard but the Run little bits was really really trivial and it allowed me to be very successful despite it being 100% custom JavaScript there was no Frameworks we didn't even have grunt I introduced grunt like six months into this process so even the build process was a bespoke script and so it's like you know why was I able to be so useful so quick maybe there is something about this that's that's really interest like maybe this idea of spending one hour maybe that's not fair but maybe saying if every every single time you have to do something in your system you have to spend hours just getting up to speed on how this particular part Works maybe there's something that's a little bit goofy about the whole situation if you can't run it fast debug it fast then something's wrong maybe that's a better way of saying it is that if you can't run and debug fast then something's wrong because there's always some amount of hour spent just learning the thought process of how somebody arrived to this conclusion especially if it's something complex like imagine if you were given a kerning bug on a kerning system there's like so much stuff you'd have to learn first before you could even become remotely useful but if they had a really simple running system you potentially could solve the kerning bug not even knowing about kerning right like that's that's real you could do that on top of that Tech deals a lot of time with itself instead of delivering business value managing these many systems and components takes knowledge and because there are edge cases there are many bugs combined these lead to low efficiency to uh to too many developers and to high costs yeah there is a weird explosion of things that just generally happen I've never been on a team that does not eventually have a bunch of people working on stuff that feels confusing to me right like at some point there's like three people that are always working on a JavaScript build system but the JavaScript build system always feels like ass and I'm not sure why I'm sure there's a real problem that I don't understand I'm sure there's a real reason why things are difficult but I just don't get it so I'm just like why why is this ass why does this feel difficult why are there full-time Engineers working on a build system yet the build system still sucks what is going I love how ass feels though yeah yeah I get that here comes radical Simplicity what is radical Simplicity radical Simplicity means having as few components and moving Parts as possible reuse technology for different purposes instead of having a new moving part for each purpose instead of using postes as a database Druid for an event store redus for caching rabid mq as a message queue and elastic for full teex search use a hosted postgres as a database for full Tech search HTML caching publish And subscribe and an event store with time scale DB this enables us to have deeper knowledge move faster and have a faster onboarding of new developers and have fewer things that can break no upgrade planning for a dozen of Frameworks or com and components and more developer happiness core to developing is getting into the flow developers are much more productive when inside the flow than outside the flow breaking components upgrading and edge cases of databases you need to read about break that flow this is dude we were literally just talking about this sometimes you just need a postgress database sometimes why don't you just start here you know until you f until you feel the burden of scale start with just an effing database it is shocking how many people pre-plan for all this caching for all this really high performance stuff for all this message cue for everything they need like especially like if you're Dr dropping into elastic for fulltech search for their delicious for their delicious delicious Json searching mechanism and all you really need was some pretty simple stuff like I don't know about that like something about that is just it feels so emotionally painful which is why why are you committing to such intense stuff when you just need something that is so simple we have vector search with 10,000 users yeah you don't like postrest has a lot it has a lot it has a lot of distance long before you need much else yeah postgress has 90% of those features but I understand there comes a point where you can't use postgress for everything right like there's a point where you have too many people and there's too much like actual searching there's too much writing there's too much locking and there comes a point where you can no longer just use a single instance you can't just vertically scale your machine right but you should consider first vertically scaling your machine until that thing costs way too much to continue to vertically scale it or it becomes impossible or it becomes untenable then guess what you probably are just fine you're probably just fine you don't need web scale 90% of people will never reach the point where postest is no longer viable 90% is a very generous based as hell scaling advice dude it's so true people reach for horizontal scaling long before they reach for vertical scaling which is just like kind of like a weird way to go like vertical scaling is pretty easy cuz you go like this if you use flight like if I jump over here really quickly and I open up my little I I quickly open up my fly yaml watch this I'm about to vertically scale everybody stand back boom I just vertically scaled did you see that you know what I'm going to do it again I literally just can handle twice as much oh oh oh what was that you you want some more boom 16x my memory 32 times my cores just like that Kazam Shazam oh what was that we need even more performance bam look at us we're scaling the [ __ ] out of this thing I know can you believe that 10K USD Bill absolutely a 10K USD bill but you know what costs even less or you know what costs even more having partially vert vertically scaled like eight different instances in a full-time engineer what which one costs more I forget again is it the 200k fully loaded senior infrastructure engineer plus your 5K a month worth of instances you're now saving or is it that one 10K a month instance because you have to go balls to the wall on scaling for a while I forgot which one is it like like should we do like maybe maybe math will help us here should I use math like quick math um okay hold on 200k divided by 12 [ __ ] I can't do that I can't do that it's not 10 I can't do the math I guess it's probably cheaper this is probably cheaper it's probably cheaper it's honestly it's probably cheaper if you really think about it anyways this enables us to have deeper knowledge move faster having faster onboarding of new developers having fewer things that can break no upgrade planning for dozens of Frameworks and components I've already read this section but I completely agree with it base camp Oh damn people going to get triggered DH G mened the creators of rails do radically do radical Simplicity based Camp can we rename base camp to based Camp can here we're going to go on Twitter um let's see uh uh this is dude this is gonna piss people off on on Twitter you know what never mind I can't piss people off on Twitter okay you know what that's it that's it that's it you need to come on stream this guy wins he's now on he's now a part of things uh I was going to say uh uh petition um dhh uh to rename base camp to based Camp bam anyways I love I I love when I go on and I'm getting ready to say something stupid or kind of like just dumb to say and then I get totally hold my beard right like in the middle in the process of attempting to do that all right base camp wrote their hey mail application with HTML and no react stack Overflow does this by running their services with small amounts of real Hardware there was that one thing what was it we read yesterday or two days ago where it's just like I don't get it how how does how does stack Overflow only have $5,000 a month in server cost we're currently spending like $50,000 it was some like outrageously High number versus outrageously low number and someone responded with you're using PHP it's just like yeah sometimes you have to use a faster language this was also back in like 2010 when PHP was or 2 whatever when PHP was just like actually super slow now it's like not that bad now you can run quite a bit of users but back then you couldn't write you couldn't run a whole bunch of users it's ironic that all the AWS questions are answered by Microsoft squeal server running on real Hardware no graphql no react no CFA no webpack no kubernets is it ironic is it ironic I think the only thing that's ironic is saying the word Microsoft squeal server okay that is actually offensive can if you just just honestly I think this article would have been perfect if they would have said postgres and not that now that you said that I like what am I supposed to do with this information now all sudden I hate it uh you can use radical Simplicity too radical Simplicity is radical a monolith that splits uh spills out HTML that is refreshed on the browser side with Hotwire Turbo with minimal JavaScript uh yeah you can also do that with HTM X you can do with lurl and Livewire using only managed postres as a database for data storage for Json job handling as a message cue and a column columnar uh columnar I can literally never say this word uh stored as your data Lake and data warehouse if you can't resist by the way data Lake are we talking about is that related to uh the same kind of like the dying process on oils uh if you can't resist then add redus for cashing because Reedus never breaks it's kind of funny it's kind of funny I the thing is is that this works probably for your application can we just be real for a second this that probably works for your application it's wild that this exists okay the thing is I do want to I I do I do think you more people should reach for this than this I'm not saying don't use serverless or do use serverless or don't use versell or do use versell or netlify or fly I like fly I use fly but fly allows you to kind of build it yourself the reason why I like fly is because if you want to Raw Dog a TCP connection on fly you can do that you can have a single machine that runs for hours you can have it go up and down you can do this you can do that you can kind of like you can run fly the way you want and it's pretty simple right AI just died so fast or am I living under a rock no no AI is just most AI is just stupid many startups with only a few customers have uh several microservices aedus postgres elastic kubernets web pack a JavaScript Spa rest API graph quel with Apollo and Kafka and or rabid mq for message Q or job server compare this to a radically simple setup that only uses Hostess post Gres instead of all these things unpo to render HTML on the server in a monolith and big query for analytic Warehouse I think I think I honestly now that I'm thinking about this I I think where some of these problems come from is that there's these stories of people that have to go from a monolith to some sort of microservice based architecture or they run into this problem where they can't release anymore because things are too difficult due to their monolith application and I I I think that all those stories gave people allergies to solving problems but instead to solve problems that could happen that could happen as they scale into the future like I agree that transferring from a monolith app into a microservice thing would be very hard and when you get to the point where your monolith application is actually struggling like I I actually fully agree with that that that that is really a difficult thing and that's going to be a difficult transition but I also want you to remember that if you're struggling at that point you probably have what 20 30 40 50 Engineers you probably have actually created a successful company you probably have millions upon millions of dollars in Runway you know you're you're probably in a good place to make those decisions you probably can do a good job and maybe just maybe it's okay then to complain about man this is really really hard but man you know what's really good I didn't waste all my time and I was able to get to the point of earning money before I made this problem by the way again unhappy engineer appreciate that thank you buddy I'm in the middle of doing this you know what I but but you do actual software engineering your monolith is probably not that hard to split up a couple mess uh messes are hard regardless of architecture this is true whether whether or not you're in microservices or monolith just absolute slop thrown together will always be hard like can we just be real for a second even good architecture no matter if it's microservices or monoliths to change from one to the other is hard I don't think there exists a world in which that isn't a hard activity and to think that one is somehow like saying saying that going from a monolith to microservices is super hard is not indicative that monoliths are bad right it's just that scaling is hard it's hard no matter what because you have to make just crazy decisions like you don't need to make the like this idea of distributive data warehouses where you could have you know failover and eventual consistency like that only exists in a world in which one machine can't run the requests like it's hard why would you do that to yourself a much smaller setup that achieves the same but has fewer moving parts that need to be maintained learned and debugged many fewer components need to be monitored adding uh added to a logging server and alerts created do some companies need that complex setup when they have 50 plus developers and millions of users yes do most companies especially in their first years need that setup no agreed let's go radically simple just do the just view KN webpack bables JavaScript Spa rest API qual postgres Reddit elastic search kubernets when you when your needs grow in more moving Parts but uh but slowly challenge yourself if you really need that new part radical Simplicity means extending your existing technology first for example if you need a rest SLG graph Quil for Native mobile applications use hura to automatically create rest graph coil from postgres database that sounds kind of night marish I don't think I I I don't I typically don't like this word whenever I see this to me this seems like this is going to be a headache I think I'd rather just write the simple quote to H to have you know API you know or Json slash or whatever you need to do to have those two apis as opposed to I bet it's not even automatic I typically am very skeptical of anything uh that has autom magic to it because I find that whenever you do that it's really difficult graph by itself is a bunch of automatic generated crap yes typically when you do that it sucks all right you know what I have to get up I have to pee flip take it out dude I just drank too much everything this morning is radical Simplicity the same as choosing Bor or choose boring technology it goes in the same direction reducing risk and increasing efficiency I want to see what what is CH choosing Bor boring technology I'm curious uh let's see what what is boring technology because it almost seems like today boring technology it's hard to know what boring technology even is at this point I I want to go read that now but I I I don't know that I don't know if we have that PHP not Boeing technology boring yeah we don't want Boeing technology golang goang is a great Jango Jango goang boring uh it goes in the same direction reducing the risk and increasing efficiency while and while choose boring technology also addresses the number of pieces if each Tech is expensive you should pick a few it mainly focuses on choosing proven technology and with proven technology you can still create complex architectures and setup combining radical Simplicity with choosing boring technology results in the best outcome choose post grasses what this whole entire thing is just use postgress radical Simplicity also works with existing or ex it must be existing existing technology if you have enough money to hire those few Engineers proficient in it but it's much easier to go with postgres pre-read that was so pre-read pre-read let's see much easier to work with postgres instead of nifty new database and PHP let's see and PHP instead of a funky new functional language I don't know o camel's pretty cool I would I mean it would be fun to have a job in O camo for a while uh there are many more positive side effects of radical Simplicity features get delivered faster Founders need less developers to deliver more the company can move faster can easier adapt and can easier pivot it to something else radical Simplicity gives your startup a much higher chance of success instead of failure if you are a Founder insist on radical Simplicity Indie hackers they're they're actually I have a friend his name is rocks uh rocks codes uh rocks codes uh at one point he tweeted that um he tweeted something along the lines of I have more microservices than uh than uh users and I'm deep like he was deeply unhappy trying to get Amazon and all these things cuz he was building out some hyper scaling thing and he realized how stupid it was to build out all those stuff and it was just so funny watching like this tweet Storm from him of him slowly losing his mind using all these Technologies to build stuff when he could to just build something small because you know there's only going to be a few hundred users a thousand users 10,000 users anyways so it's just like I loved it it was one of my favorite like Devol like the uh the the destruction of one's mind on Twitter can you love radical Simplicity as a developer it isn't all about new techn IES isn't that what brought you into programming in the first place I think what brought you into programming is the challenge of solving problems yep that was for me at least uh I some people I I I'm very curious of just using new technologies is the reason why people go into programming maybe that's the thing but for me it was just the problem solving nature the challenge should not come from learning new technologies but from solving deep problems oo I like this oo I like that uh with more time on your hands it's easier to solve challenging problems in the domain with new algorithms and deep features than let's see that astonish users and not shallow features like storing data in a database from a form hey you know if you could store my database values though that's pretty impressive I I will say though that like right now I'm trying a new language out right Zig um and I've absolutely enjoyed using Zig it's been a lot of fun using it it's been really really interesting using it but I'm using it by solving a problem that I've never solved which is creating my own game and so most my time is spent thinking about the game a little bit of my time is spent about learning Zig and now that I've learned Zig for the most part I think I pretty much have everything I need to understand Zig to be you know decently effective it's just been a lot of fun and so I spend all my time building the problem not learning like not storing the data as he says if you find yourself just doing that I feel for you don't try not to be there how not to be that senior Dev who's uh who's a senior because they spent x amount of time at a company um well ask me another time baby come on we're in the middle of something just hold on can you do radical Simplicity yes as a Founder you need to manage your CTO otherwise he or she will build a Dream Castle of technology is that true uh uh if you're already following Lean Startup for maximal chances uh for your startup radical Simplicity perfectly matches lean startups on the technology side of things radical Simplicity forms a trinity together with Lean Startup for for a business and scrum for process okay now you lost me dude this article was just like completely on track or it just completely went off track out of nowhere how can you argue for radical Simplicity and scrum at the same time what the hell just happened can somebody explain to me how did that just go dude how did that dude did did how Uncle Bob doesn't support scrum okay we talked about it Uncle Bob and I had a talk on stream about that and he talked about it not being great uh it enables uh to experiment fast deliver early and pivot if necessary uh a bloated architecture ties you down and sabotages your Lean Startup Endeavor I do agree with that but man crazy statement here as a CTO you need to build an environment where people can grow and experiment without relying on growing Tech zoo instead find challenges from businesses that can be solved with your inventions your cleverness your Ingenuity and algorithms and not by more toys from the Shelf it's an interesting proposition because most the time you don't need to invent something you can just like this is like this is the big conundrum of today's software development which is from one side of the world you're going to hear don't reinvent the wheel right and then from the other side you pretty much hear invent the wheel and so which one do you choose do you use the fancy system that is promised to do everything correct for one thing or do you just use some off the shelf or do you just use what you already have to kind of create some semi verion of it that just fits just your needs what happen if your needs change all those kind of things you know people ask all these questions and I think that's how they end up going on this side of things where they just use these off the shelf super Solutions why like we were just talking about it effect JS right or effect TS or whatever it's called somebody wants to be able to have a function that can throw return a result object and then just want to make sure that they can have results as values so they bring in an entire library that has throttling that has debouncing that has everything just to have one feature and sometimes you have to ask yourself does this make any sense does this approach to life make any sense because eventually you have like 10 libraries that do a whole bunch of things and you're using one feature from E each and all you really needed was an async Q that's like what 16 20 lines of code with error retries I think it's about 25 lines of code live by the wheel die by the wheel like real talk like I can't tell you I've seen people bring in effect JS specifically effect JS for an async request queue and I literally used to use async request queue as an interview question because it's such a simple problem that you can write in 30 minutes if you're unexperienced with it and you can probably write it in 15 minutes if you know if you know the problem domain at all like it's that simple and I'm just like dude what okay like I get you don't want to write stuff but you just spent an hour learning and reading the docs for something you could have written in a half an hour yourself and then change to be just our needs and it blows my mind and you see this all the time uh for my proudest coding moments were figuring out an algorithm for towers of Hanoi as a kid and writing my own full text search way before there were Frameworks like Lucine fing Lucine Google search has a simple UI but a deep domain when you enter 2 plus 2 it doesn't search for this term but prints a calculator and shows four this is a deep feature that users enjoy uh it can be done so do it radical that's funny that they mentioned Google because Google is like the opposite of radical anything they they they literally just kill product after product and build like half baked versions of everything and then call it done radical Simplicity takes all all the technology that doesn't deliver custom value radical Simplicity leads to deep domains and deep Tech radical Simplicity lead to higher quality makes everyone happy makes it easy for new developers to understand the system I love this one this one's great this is great this is great this is great this is great make setting up and testing easy this is great also by the way he doesn't mention SQ uh squeal light which I'm a little bit shocked about because squeal light if you don't if you're not familiar with squeal light squeal light operates on files it's really good and if you want to test something you could literally have your golden database setups as a file and for your testing process you literally just CP the the file then run the test as if it's a full ass integration test right like that's crazy that you can do that that's amazing right like when you have to do a database and you can just CP the perfect state in you're like huh that's pretty awesome squeal light solves so many cases especially in CI yeah it's wild how good squeal light is and squeal light has been being Rewritten they have lib squeal now which is really really G great by the T folks like there's a lot of really good stuff out there uh puts you back in control radical Simplicity wins all right so about uh Stefan as a CTO in interim CTO CTO coach and developer Stefan has seen many technology departments and fastrowing startups this is where the idea of radical Simplicity comes from because he has seen too many complex Set uh setups that costed money and had their problems by the way shouldn't have recommended scrum I'm still a little bit hurt about that he taught himself coding in a in a department store around 19 81 with a Vic 20 basic and went to write code and was paid for many of them in a Commodore 64 basic uh 6502 machine code CPC basic z80 machine code 68,000 machine code amga basic GFA basic Blitz basic Q basic I started on Q basic turbo Pascal modulo 2 uh obon Deli CC plus plus list prologue what the hell are you doing in prologue every now and then you see these people talking about how they're using prologue what do you do with prologue just a real basic [ __ ] coming in here yeah but real what do you do with prologue as far as I can tell the only thing you do with prologue is being like Sharon wants a corner office but Bill wants to be next to Sharon and then Bill can't be next to Bob but Bob wants to be next to Charlene and Charlene does not want to be next to Sharon what's the setup and it's just like bloop bloop soft like what what are you doing with prolog I don't even know I don't even know Pearl python Java okay now you're just mentioning things you've programmed JavaScript Scola earling hasal typescript go and rust amongst others I just doubt you actually have any like can you really have deep expertise in all of these or have you just written them because then if you just have written them then I could pretty much say all the same languages using Vic 20's uh Sinclair's c64 sharp pocket uh pocket computers cpc's Amigas bboxes alter STS MS DOS machines window machines Linux pre distro Ma maches Suns sgis NEX cubes is that like GameCubes but different and many uh quades IMAX Mac cubes MacBooks Mac Pros iMac proos Stefan has founded several startups and worked on small and large companies as CTO uh after he sold his lat up lat latest startup he took up CTO coaching you can find him on LinkedIn he also wrote a CTO book I really loved the beginning of this I really am disappointed by the the the scrum but overall this is a great article and I think a lot lot of people need to just take this approach to most things please be a bit more radical with your Simplicity and also in your management don't jump into scrum you really don't want to scrum master and scrum and meetings and planning poker and Retros and post-mortems and every last little bit when probably all you need is three developers to meet once a week for 15 minutes and say hey these are the things I'm doing I'll see you next week bye everybody and then you meet again in like you know five days if you if you need to meet every day to Pivot that fast you've done something wrong okay and here's the deal if you are pivoting that fast you probably are a very new startup and if you're a very new startup you probably don't need standups for your developers to communicate they're probably talking all the time anyways because they're constantly stepping on each other's toes because the code base isn't that big and you're just trying to figure out everything you're doing so this is just a bunch of [ __ ] on the entire like the entire proposed management system gosh just making me angry the name is the primagen