lol I went to school for aerospace engineering and their was this professor in a propulsions class that said, “we compare hard thing to rocket science, but rocket science is mostly plumbing”. I didn’t end up building rockets but I always try to remember that the really genius things are a lot of simple concepts built on top of each other (very neatly).
Rocket Science is all bells, whistles and slick advertising after Von Braun. But that's NASA just like any other agency that soaks up billions of dollars to basically look important while adding nothing to the actual working code.
It's honestly a really good parallel - the most amazing part of rocket science was figuring out how to make the rocket go flying up into space without exploding in the process. That's a solved problem, at this point. There is still room to innovate, but most of the job is building the thing that geniuses 70 years ago figured out.
@@daphenomenalz4100 lol we definitely do. Or college. I've noticed over the last few years that people have been using "university" like brits do (e.g. when I was in university...) and they didn't used to. We still don't use "hospital" or "holiday" like them though. It's still "I'm going to THE hospital" and "I'm on vacation" for us. But I think it's interesting that that usage of "university" or "uni" is catching on here.
I think you need to clarify what you mean when you say "scrum" because everything in the article was very reasonable and I think you have a different take on Scrum than primeagen
You overlooked TIME. One overlooked problem with the overly complex environments we have today is not that we want them, or that we decided to get them and build them. It's because they grew like a Coral Reef. The technology parts, products and architectural layers accumulated over time. Each piece probably made sense at the time. Retiring or replacing parts is hard. And over time you have to get all your pieces working together. Eventually you have something that's not pretty but hopefully functional. That's just the real world.
theres other end to this too. simply using hacks, patches everywhere and creating bad code. go for simplicity, not easiness. do it cause its simple, not easy...
Reminder that what terry was talking about were things like _the linux kernel_ which are complex not because its designers were dummies but because they solve real problems that people have instead of being bedroom projects like templeos. It's easy to keep your stuff simple when it's useless.
@@isodoubIet because certainly all products in the real world need to be overengineered. I suppose Terry can't have right opinions even when he makes """"""bedroom projects"""""". You can admire simplicity (comparing any BSD or Mach or Inferno with Linux), you're aware of that, right?
I don't think we love complexity as such, I think we love feeling like wizards. And a lot of the work is not wizardry, it's bricklaying and plumbing. Edit: LOL just reached the plumbing part. Well then.
... your comment reminds me of when i started to learn programming on my own and gave some comment on some fb group about posts of "spaghetti" code etc... everyone tried to sound smart geniuses etc... i just gace my input after what i think of high-level languages and scripting in general... that 95% of time you're not a wizard, but a peon... ur just glueing APIs together... not actually making anything useful... so i agree.. Bricklaying is a good metaphor.... .. to me wizardry is more like... when my friend accidentally when drunk puts a parental control on his steam.,,. forgots what he used... and then uses wireshark to do magic and brute force it in less than a day, without getting noticed or banned from valve.... that's wizardry to me
I think if you want your self to be labelled as wizard then create some big shit like linux kernel like what torvalds did other wise just consider yourself soy dev and move on 🤷🏽♂️🤷🏽♂️
No, we like complexity. Makes is feel smart to know something most people won’t bother to learn. Not because it’s useful, but because we can feel smug about it.
My father warned me against getting into computers because you end up doing nothing but plumbing. I thought what does he know, as he had never owned a personal computer in his life. Turns he did know more than I could possibly imagine.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. - Gall's Law
"A complex system designed from scratch never works" You can use formal methods to design complex systems and formally verify that they will work before implementation. Processor architectures, for example, or other complex hardware systems. Amazon also uses some formal methods for their distributed architectures and they manage to deliver massively complex working systems on schedule in time for re:Invent each year.
@@fennecbesixdouze1794 Surely processor architectures are a prime example of what was being talked about? 8086 was a hell of a lot simpler than x64! Modern implementations might well be done via formal methods and design software but they inarguably evolved from simpler working architectures.
The complex system evolved from layoffs and new employees that have no idea what they're doing. Add to that lazy managers with no sense of leadership and you have the spaghetti code mess we have today.
I spend all my time on planning. And none of my time on development, or solving problems. I have accomplished nothing. Therefore, I have optimized for simplicity.
One of the reasons why I enjoy working with trading exchange services is that we literally have no CPU time left other than what we use for business code and service reliability. The only way to reach tens to a few hundred microseconds of RTT is by running the code with zero fat and waste.
don't reinvent the wheel, but lean on publicly available knowledge on how wheels are constructed instead of licensing the wheel factory for X dollars a month because you need 4 of them.
@@parkourbee That is the exact scaling issue in this video. If your product uses wheels, but isn't wheels, don't turn it into two projects by trying to build your own wheels. Just buy them from an existing wheel expert and work on the real project. When the project is good and making money, then bringing wheels in house might be a good idea.
@@barongerhardt I agree for some things, but some wheels, like auth, often need to be fit specifically to your car. Other wheels, like analytics, can be self-hosted like with Plausible. And then of course there's npm install wheel.
@@parkourbee He says later in the video, not to take a the complexity and problems of a whole lib just for one short, easy to implement function. These as well as thin vs thick client are parts of the art. Early on, in almost every case it is better to buy as many solutions as possible. Then as things grow, pick the things that are causing bottle necks. Then comes the cost saving efforts, from easy to hard.
Simplicity enables speed. And more importantly, it enables the idiots who come after you to understand what you did so they don’t feel the need to tear it all down and rewrite it.
Previous job was maintaining a 15y+ old B2B app that had a postgres db for 20k users, ~1tb data. We had upgrade servers whenever Linux ran out of updates. For performance it was always "add index".
It really bugs me when people don't differentiate between complexity and complication. (Admittedly, the distinction is kind of systems science jargon.) Complexity is when a few simple parts lead to lots of rich behavior. Complication is when you have a giant pile of exceptions. Lambda calculus is complex but uncomplicated. HTML is uncomplex but complicated.
People love complexity. Looove it. Relish it. I have a colleague who's constantly stressed out and complains about convoluted legacy solutions. Yet he excels in designing the most complex solutions where seemingly simple tasks can grow indefinitely in lines of code. And he fights me whenever I point out that this or that could be made much simpler or that he shouldn't implement something until it's actually required. Most developers I've worked with has been like this to some degree. They love being "smart", love introducing new design patterns or frameworks or a fancy nosql technology or establishing message queue contracts or refining some foreign key constraints. And they loooove discovering "problems", that is hypothetical issues that nobody has experienced yet. I'm sick of it.
Dude I wish you were on my team. I have the same arguments all the time. Simple SQL database and java or c# or go or some other reasonable back-end language for a back end api, then html/css/js in static files for your front end, and your first 10K users will be fine. If you are fortunate enough to need to support more than 10 thousand users, you will find out that the bottlenecks are not where you thought they would be, and you will be in a much better position to design a more scalable solution for your particular needs.
@@freeideas thx u. I work in a small telco. We have some 70,000 users (depending on how to define it), but even with this simple stuff still works wonders. Sometimes the amount of code exercise some of these "clean code" dudes produce is amazing. A nightmare example is that we needed to use a third party API to get a company credit score. A simple REST API that should be perhaps 8 - 10 lines of code: make an HTTP request, check the response code, unpack the JSON, perhaps cache it for some time. Simple stuff, right? Wrong. We only had use a single endpoint from this API, but some genius thought "why don't we implement a clean internal interface for all of the endpoints exposed by this API? We could use it in some future projects". The stupid thing ballooned to 3,000+ LoC across dozens of files, with inheritance trees, interfaces, etc etc.. with a full unit testing suite.... for doing a simple HTTP request and unpacking the response.
True. Many times it's Resume Driven Development. Even if the project doesn't really need it, they'll bring unnecessary stuff to have "professional experience" on them to pad their resumes. They also typically love whiteboard masturbation and/or complicated abstractions that cover a wide variety of usecases (most of those usecases never even arrive, or have very simple alternative solutions). Developers love complexity lol. They want to "grow", never content with building a simple solution that just works given the project scope. It hurts my soul seeing simpler solutions getting "scalable" and "dry" by them when there wasn't any need for that scalability or dryness. But they're the ones getting pats on the back for being "productive" (producing more code, when most of it isn't even needed) and they also get to make their resumes padded which helps them in job hunts for higher salaries.
Although I generally agree with you, I recently had a problem with this statement: "And he fights me whenever I point out that this or that could be made much simpler or that he shouldn't implement something until it's actually required." Funny thing is, I implemented a thing that is not required yet, and is still not required. However, I spent this whole week, editing, like, tens of functions just so I can have this one 'seemingly simple but required' thing working, that I didn't think of in the first place. I think this is one of the 'hard problems', and that it get's easier with experience (never solved). I even saw 'TODO:'s in some of these functions that I wrote myself.
@@ThaSPAWN it's part experience and part Texas sharpshooter fallacy. Without fail, every one of these premature abstractions and preemptive implementations done by my colleague has turned out to be hindrances rather than actual help. Incidentally I lost my temper with him yesterday. He was supposed to implement a simple set of messages to be routed on an AMQP channel. The messages should tell the router component where they should be routed. You'd think that should be a simple task of defining an interface with getExchange and getRoutingKey, having each of the 10 or so message types implement this interface and be done with it? Wrong. I'm looking at two levels of inheritance, a special configuration class, and a configuration dictionary. I mean ... Why? Why on god's green earth would you do something like this? I confronted him that this was way too convoluted and complicated. He just replied, and I'm not paraphrasing, "I like this level of abstraction. This is my coding style. Not everyone likes simple code like you do.". I'm not making this up.
We got a new project at work. The business logic is about 120 lines of python parsing code slapping that stuff into an SQLite Database that gets packaged with a go app into a container. The business logic is essentially a few lines of SQL. The frontend however is an Angular app that has a few thousand lines of typescript already...
SQLite is about 116k lines of code, Go is about 167k lines of code, and python is about 154k lines of code. So your backend project is actually about half a billion lines of code.
I'd bet $100 that the front end could be written with fewer lines of plain old HTML/JS/CSS in static files, than with Angular/React/Vue. With cherry picked use cases, these frameworks save you a lot of code and complexity. With real world, these frameworks force you to write a monstrosity.
@@fennecbesixdouze1794 If you count lines of code in the back end components (even in the COMPILER!), then we have to do the same thing for the front end. The Angular app runs on a web browser, most of which are many millions of lines of code, and the TS compiler is about 250K lines, and should we count the javascript engine that the TS compiler runs on? So if you want to compare lines of code this way, the front end is still enormously more.
@@fennecbesixdouze1794Right, then let's also count lines of code for operating system you run on, IDE, git, git server, server hardware code and literally everything that is somehow involved
I am working on a project that has 4 Teams totaling 25 people. We have 5 Java microservices, 8 AWS lambdas, a mongoDB for main storage of data, 3 AWS SQS queues, 2 nextJS frontends, redis for caching, dynamoDB for storing some other random stuff and 12 AWS SNS topics for what is essentially a CRUD app that sends out notifications when something happens. I have no clue how we ended up here. The local dev environment, building and shipping is hell.
I work at a company that is having trouble pushing its monolith app further to service our clients. We have 5 developers and I'm pretty sure ownership doesn't have tens of millions of dollars of runway. The problem is not that our user base is so large (it's on the order of tens of thousands), but more that we tend to get pinched really hard at certain times and can't scale for momentary needs. We also have an enormous amount of data to keep track of despite the small user base (and it really matters for our users, we're not just hoarding data). Poor architectural decisions that evolved over many years also plays a significant role.
@@haydenflinner like gigabytes? yeah if not larger. hundreds of tables, hundreds of millions of rows in some, query times in the minutes in some cases, far more factored out tables than there really should be ("single source of truth" taken way too far)
The problem is developers buying into the current thing no matter if it fits their project or not. Why does a CRUD app for a handful of users need to have a bunch of microservices? Why not a modular monolith? The predominant dogma in the developer community doesn't even allow posing that question.
Agree with Prime, apps are more complex nowadays. I remember trying to write partial page reload by hand and it was so tedious and so annoying and bugprone, that I hand rolled my own library to handle it. I couldn't possibly imagine working on a website like that in a large organization doing it by hand. Nothing would ever ever work for longer than a day.
@@vaxrvaxr Something like that. I did intentionally misunderstand and oversimplify my response to @FeLiNe418 in an attempt of humor. However the statement could be expanded into a discussion. What is a one-liner? What is refactoring? Was the intention to communicate "radical simplification" by removing code? Consider taking 200 lines out of a 300 line mess and refactoring it into a separate function, the statement would be satisfied, however the phrase "refactor into one-liners" would carry different meaning. Consider removing a home-rolled caching solution and replacing it with a common third-party library, this could be considered "refactor into one-liners". Does any of this create joy? Is joy so created a relevant KPI? Why not?
Most people that go into engineering fields (of whatever sort) _love_ complexity. Unfortunately, engineering is the process of _removing_ everything that is not necessary to achieve the goal. Obviously that is incompatible with flagellating yourself over how superior you are for being able to build and figure out super complex systems, so we end up with a lot of bad engineering.
As backend engineer in a small agency, for me radical simplicity is choosing and implementing the proper cloud services to solve problems. But i always deeply learn about them and have at least one fallback FOSS product which can do the same on-prem. Treating PostgreSQL and PHP as golden hammers sounds horrible.
I built a major project for my last company in Django with Alpine and HTMX to handle any frontend reactivity needed, including the chat feature it needed. Daisy for UI. Built in Django features for as much as possible before relying on something else. I even kept it as a SQLite DB. I wrote only 16 lines of Javascript. When an engineer working on another project asked why I went with that stack, I answered that it was stable, battle-tested, simple to maintain, and that by the time we scale past its ability to keep up we'll have the money for a team to build at the level of complexity required for that context. Apparently, that was the right answer. Ha, he told me if React had been involved at all, I'd have probably been fired.
could you explain why he told you that about React? I'm about to start a major project using Django and planned to use React for the frontend. But since it's my first major web dev project and I'm using it to basically learn and decide on a stack, I'm curious to know why React was a bad choice there. Django is a must cause I'm doing the heavy lifting in python.
@@stefanalecu9532 I was specifically talking about Django. I should have been more specific. HTMX is as reliable as the templating engine you run it on.
@@stefanalecu9532 with this setup the app is server rendered, quite unlikely that you run into an actual htmx bug, and even less likely it has any breaking effect.
Honestly I think "The Lean Startup" should be a must read for developers, and use the same lean principals for development. Goes right to the point of using frameworks for "future" requirements when for example you have to few users and the data is too small to even need to cache anything.
96% solving problems around what we built. Our frontend is in Elm, and we somehow still managed to spaghettify it. That means, excessive use of generics, message value transformers, closely coupled library and application (application specific logic in library!), and nonsensical naming. It took a month for our team to remove a field from a form.
I call it "showing the brilliance". You try to quickly be as useful as possible, even if that means helping somebody else solve a problem and making them look good. Works best when you're not trying to be a manager.
I believe the problem is lack of modularity. Effective solutions seem to be founded on the principles of generalizing components (aka parameterizing output with input) and composing those pieces into a system, which can recursively be parameterized and composed into more versatile tools. And problems can be thought of as the dual/converse: we often start off with one complex problem and then learn to decompose it into many simple problems. Solutions can be thought of as a graph structure where some nodes are big/versatile tools that can be related to their small/specific sub-tools. Problems are also a graph of big problems related to their sub-problems. Then an engineer's goal is to relate certain sub-problems to certain sub-solutions to complete the problem-solution graph for a certain use case (collection). We can think of the solution side of the full graph as the code library / framework / toolset and the problem side as the domain. Having this modularity with only minimal interfaces between components of problems and solutions allows rapid understanding, change, extension, etc.
It feels like there's a lot of good sentiment sprinkled in with examples that aren't the best just because it's that all they know. If you're in a box all your life, then you're not too familiar with what's outside of it, and that's if you even recognize that the box exists.
If you're not sure whether you can use old technology, consider that your hospital probably only changed their front end away from Visual Basic in the last year or two (if you live in the us).
“Micro-lith” is the best approach IMHO. Declare your managed micro-services in IAC such as CDK. Treat it as one small codebase. Basic pipeline deployment.
I work on a custom operating system for edge computing and the feedback cycle can be very long. For some stuff we have python modules so we can run it on a cluster and iterate more quickly there. But to actually test how it interacts with the rest of the system, we have to run a test with the running OS. Feedback takes 30 minutes to several hours. It is unclear how we can ensure that a cluster running the OS works as intended without actually running it on a cluster
Radical simplicity works well if your project is straightforward and won't need changes, like many mechanical and electrical engineering projects where once it's built, it's done. But not every project is like that. For complex systems, you can't just assume the design is final. That's why we focus on modularisation and sometimes overengineer. Sure, this adds complexity, but any experienced engineer knows it's worth it. Modularisation isn't easy, but it allows for flexibility and future updates. And there's nothing wrong with over-engineering when done right, you learn to judge when it's necessary with experience. You also have to accept that customers often don't know exactly what they want at first. It’s part of the job to help them figure that out as you go.
I started with QBasic too, in high school programming class. My first "game" was a Final Fantasy clone, binary loaded sprites (difficult in basic but fun), and my "game" spanned several floppy disks, lol (very unoptimized). I was ahead so I learned Dark Basic, which was worlds of fun back in the day. First game with it was a simple flight sim, using two (top/bottom) randomized 3D Metrix, with collision detection; you hit, you die (simple game over message) and you'd start again (it was actually quite addicting to play, and it was like one page of code). Simple syntax but you could program 3D games, and it had game controller support built in. It was amazing! Brings back memories. Those were the good 'ol days, lol.
Re: 19:53 and the Postgres-as-everything argument. "Why are you committing to such intense stuff, when you just need something that is so simple?" Because they are in job descriptions and (I'm guessing) might come up on an interview. Tbh, I like this idea of starting with a more foundational technology like Postgres and letting yourself "grow" out of it into more specialized products like Redis or Elasticsearch. But I also feel that nagging pull of "but what if it comes up in an interview). And I'm not someone who can learn the basics of a tech from docs and be confident I can answer questions in some interview in a few weeks or months. It will fall out of my head unless I'm touching it pretty consistently. I'm fortunate that I am (fingers crossed) still employed, but if you are in this position and job searching without money coming in, yeah, I definitely understand feeling pressed to learn every new hotness if I see it in a relevant job description.
I'm an "invent the wheel" kind of guy personally, writing a game with pygame has been extremely informative and I'm loving the process, there's so many little ways to optimize
the urge to make system complex comes from the need of making system more configurable, extendable, quick to add similar features. But the problem is we devs dont always see when we need to do something once and forget about it and when we need to do actual optimization. Leading us into loop of premature optimization.
Love these videos... when i have the audio playing in bg while working I think I'm listening to Rick from Rick n Morty which gives the content even more credibility. Just need to belch n burp every now and then.
4:27 The sites did not get more complicated. MapQuest and Google Maps is a great example of the old way vs the new way. MapQuest worked fine, and Google Maps made it better at the expense of astronomical cost and complexity. MapQuest could have been progressively enhanced to do the exact same thing Google Maps does today on that old ass tech. It would be way less complicated too.
37:41 He seems to be old school. Perhaps what he meant by Scrum is the old agile way (agile manifesto), not the enterprise meeting storm it has become.
I agree, the agile manifesto has been bastartised by business, the idea of breaking down a project and iterating as you go works really well if run properly. Then again I know a ton of devs who complain about even while run agile projects because it apparently breaks their flow. My biggest push back to this is always your flow means Dickson if the product delivered isn't what the client wants, so take the pain early and by the end of the project everyone will be on the same page with what has been delivered.
Hasura is written HASKELL! I remember when you asked for one example of a real world program written in Haskell, here it is. They are also a billion $ unicorn company. Food for thought...
Sorcery was forbidden because it was trying to go a shortcut instead of doing the work. If you think of your self as a coding wizard, then likely you just want to npm install your way through the problem you are solving or bowing down before your Gippety idol instead of doing the work YOURSELF.
probably why I don't like using frameworks unless absolutely necessary makes you learn how things actually work and keeps things manageable I'm not here advocating for building an entire database from scratch, but maybe stick to using just one _(or possibly two, depending on the usecase)_ many apps can essentially just be a front-end to some database
This whole article touches my soul. Completely off of React since 2 years. Svelte is the way for me for SPAs and vanilla JS with sprinkles of Alpine JS if the case suits it better. Btw, what is the black board paint like tool Prime keeps using? GIMP? Can't be sure as the UI is so teeny.
Man, I was a webdev from 2004 to 2013ish, when I became chronically ill. It’s so cool to hear you name all the stuff that used to be normal to me. Sqlite, postgres, lucene. I get the impression everything is just frameworks stacked on top of each other nowadays. I absolutely loved the feeling of starting a project with a clean slate. Just an empty db and base project directory. Starting by creating a crud layer, some basic mvc functionality and maybe a js framework, like jquery or mootools. Man, those were the days! 😊
11:33 definitely a valid argument. An app I’m working on now is just a tool to execute calls to another API. Now there is a need to make it easier and automate the tasks but it’s nothing a script can’t do. In fact that’s how it started. Now I’m just making it persistent with scheduled jobs.
I love when I can get my head around complexity, especially when its clear that there isn't an understanding of the complexity around you, or if what people think they understand about it is not correct and that is preventing a more efficient system. That's what makes coding fun, having your understandings tested as you plow through the details until it comes together. And when you get surprised and have to adjust your logic or code when things don't turn out working quite like you thought, you learn even more about your own ability to mentally model things, and get better at intuitive modeling (sort of... your understanding reflex?) for the next complex problem.
For Postgres vertical scaling makes sense, but for stateless horizontal makes more sense. With vertical scaling each scale event causes downtime. With Postgres this is usually fine depending on service level objectives and you can retry queries to mitigate. With stateless workloads horizontal scaling is very easy, cheaper, and has way better uptime of course.
honestly speaking, I have to kind of disagree with this because I've spent most of my career, literally years, solving problems around performance constraints. which is outside of your bubble that you drew and was all done quote on quote in the pursuit of simplicity. I've really often found that the simple solution while it gets you out the door quickly it always comes back to bite you in a incredibly expensive way. I'm talking like spending millions of dollars kind of thing.
I'm interested in whether you're conflating simple and easy. I've found that simple things can be more easily refactored, and are thus less expensive to correct. Simple can be hard to achieve. Easy, on the other hand, often means coupling with something that can eventually fight everything you need to do. Regardless, you're sometimes forced to make decisions before you know what you need, and those mistakes can be expensive if the decisions were based on very wrong assumptions. Other than that, I have never experienced anything where reducing complexity and dependencies was not a good strategy to fixing something terrible. Can you give an example? (On a side note, it's called 'quote unquote')
@@Muskar2 I've been meaning to write a blog post about this actually. think I'll spend some time today/tomorrow doing it and see if prime is interested in covering it.
Inherent complexity vs. Accidental complexity. Accidental complexity = technology complexity * technology m*sturbation. We are very good at j*erking off!
Frameworks, Kubernetes, Microservices and other stuff is created to solve problems. Problems that you get by trying to be "simple" and raw digging without frameworks.
This is basically what Vertical Slice Architecture is advocating ;-) Keep it a monolith BUT make it simple but make it easy (or at least, easier) to pull components out if certain components become a bottleneck.
Postgres is also super simple to use in CI. You can pretty much copy a template DB as fast as a file. It's pretty good. Haven't tried doing this with sqlite, but it's probably even better if it fits your needs.
In 2001 I worked on web application that had dynamic UI - loading data from server and building UI on client, all state stored in DB. No React, no Angular, just plain vanilla JS, and still it worked. Internet Explorer compatible! Industry has added layers of complexity since then... for nothing. Users or businesses didn't get much out of it, but developers gained pay rise :) IT accounted for 10% of corporate spending in 2020s, and it was just 3% in 2000s.
typescript is super rich, but its biggest flaw is to allow multi type for a single variable. this is the root of complexity that developer should not do
Going vertical does not get you high availability. There, enough said (JK, here's more. I used to vertically scale on aws us-east-1. Things were great. Then aws networking and Ubuntu plus docker destroyed us. What I mean is, aws had a network failure affecting our availability zone. We are forced to live in horizontal scaling because business demands that there be masures in place against this sort of thing. Uptime matters. My application supports doctors around the world. When should I have down time? I can't. My performance needs aren't huge at all, but I can't be down. Ergo, I have 3 VMs across AZs. I'm not doing this for fun I'm doing it because I have to.)
Scaling horizontally and availability/redundancy are not the same thing. You can scale vertically and still have multiple availability zones / backups.
A marketing site should use something like Astro. This is because you almost definitely don't want to ship large amounts of code to the client in order to show the site. You want primarily HTML and CSS shipped. React Server Components are the way to do Astro without doing Astro, except not as good for static content.
16:42 I also worked at Workiva, though from 2017-2020 (you can guess why I left based on the date). It was mountains of complexity, especially on the frontend. That being said, you quickly learn which mountain trails you enjoy and which mountaineers you enjoy climbing with. 😄
For my start-up, im still bashing my head against too much complexity, but because I'm not a developer myself, i opted for well known technologies that are well documented and for which there are plenty of devs. Managed digitalocean postgres and redis instances, droplets running Laravel. Unfortunately a react frontend, which i now regret. I now wish i had just used wordpress for it all the way and just created drag and drop custom fields instead, but i still feel like i dodged a massive rocket
Trying to make things simpler is a huge challenge. If this was about being challenge, pick that one. Caring about maintenance, developer experience, code simplicity.
Jonathan Blow is putting these very similar and familiar sentiments into a programming language's ethos he'll hopefully release soon. Before Silksong or GTA6.
Organisation are also pretty bad at determining when stuff should run on servers at all. This is especially prevalent in mobile apps e.g. why would I ever want to generate thumbnails for pictures on my server, if it's being uploaded from a device that is literally build to excel at this kind of thing? Just write the damn code on-device. You aren't going to kill the battery. It's fine.
It's simple for monolith situations. Instead of trying to start with some kind of micro architecture trying to solve problems you don't have whilst introducing a bunch of problems you didn't envisage, just run monolith - then one day a portion of that monolith will be better served not being part of the main stack due to mass-usage or heavy computation, or simply that it doesn't need to run immediately like sending an email - so pull it out and put that into it's own service with a message queuing system. Rinse and repeat
So in actuality, you're using HTML, JS, CSS, jQuery, PHP, MySQL or MariaDB, phpmyadmin, Apache or nginx, and _hopefully_ some kind of stable Linux distro underneath. I'm saying "hopefully" because otherwise you're using either a rolling-release distro or Windows to host a website, and I'm not sure which is scarier. Just because modern magic hides the complexity of your setup, doesn't mean said complexity isn't ready to ruin your day when you least expect it. Gotta be aware of your setup's true complexity, no matter how simple it seems compared to the alternatives, or you'll end up with a server full of footguns.
@@genxer1824 i think youre simplifying the mountains of complexity that is built on top many of the same features you mentioned. Its not like these arent included in modern stacks, theyre just hidden, along with all of the added build step complexity and redundant client side logic like auth, routing, etc.
confirming when web app is not so big that can reload page almost instantly it's not worth the complexity with SPA-s. I work in university and we developing a web app (database for all data related to education processes) and it was started with vanilla js, php on server and a single database. later we added vue components for some more complex UI controls, but not the entire page (mount just in small partrs of the page) I was actually surprised to see same approach later somewhere (maybe Astro) called "islands of reactivity". it works fast and maintenance is easy (with our limited human resources) because code per feature is not big
All my new projects get written in PHP now for speed and simplicity. If, after a few days, it seems like some advanced stuff is needed, I'll rewrite in something else, but it's rare that it happens. Because some code has already been written, it's easier to think "Do I *really* need that thing though?"
The same thing happens on the factory automation industry (and I'd argue that in many other fields this is a thing). A standard is set, the standard is used and abused beyond what it was made for, the standard is updated to work better within those wildly expanded requirements and that ends up validating the hacks and convoluted solutions. Just look at how many "naming conventions" exist for sensors and other devices on a factory because at some point someone decided that it'd be a good idea to give the smallest size possible to a naming field, and those conventions have been kept up for backwards compatibility.
It's funny, I'm spending this time working on SQL serializers for a Django server that will then send slightly differently structured data to my React FE to enable new features so that I can start building the thing I set out to build 4 days ago.
Learning Python for work, and ended up having to make a program far beyond my skill level. As Prime stated, I just tossed it together using something simple, that would work, figuring I can go back and make it pretty later. As long as it works, that's all that matters when it's crunch time I think. I am looking forward to ripping into it though, and seeing what new things I can do to accomplish the same goal
Problem is, we try to build illusion that everything happens at client's browser in real time, while it happens on the other side of globe and sometimes take substantial amount of time. Which is impossible. And bigger the discrepancy is, bigger chance illusion breaks.
lol I went to school for aerospace engineering and their was this professor in a propulsions class that said, “we compare hard thing to rocket science, but rocket science is mostly plumbing”.
I didn’t end up building rockets but I always try to remember that the really genius things are a lot of simple concepts built on top of each other (very neatly).
Right? I taught theory of computation to 20 year olds. When one of them would see how easy some of those concepts are, it was a great moment.
Rocket Science is all bells, whistles and slick advertising after Von Braun. But that's NASA just like any other agency that soaks up billions of dollars to basically look important while adding nothing to the actual working code.
It's honestly a really good parallel - the most amazing part of rocket science was figuring out how to make the rocket go flying up into space without exploding in the process. That's a solved problem, at this point. There is still room to innovate, but most of the job is building the thing that geniuses 70 years ago figured out.
Do people in the US refer to colleges as school too?
@@daphenomenalz4100 lol we definitely do. Or college. I've noticed over the last few years that people have been using "university" like brits do (e.g. when I was in university...) and they didn't used to. We still don't use "hospital" or "holiday" like them though. It's still "I'm going to THE hospital" and "I'm on vacation" for us. But I think it's interesting that that usage of "university" or "uni" is catching on here.
Ah so this is where the traffic for my website is coming from :-)
Hey, nice read!
o7
I think you need to clarify what you mean when you say "scrum" because everything in the article was very reasonable and I think you have a different take on Scrum than primeagen
Where's the explanation for that Scrum take? Can't see it.
Congrats on being PrimeDotted
You overlooked TIME. One overlooked problem with the overly complex environments we have today is not that we want them, or that we decided to get them and build them. It's because they grew like a Coral Reef. The technology parts, products and architectural layers accumulated over time. Each piece probably made sense at the time. Retiring or replacing parts is hard. And over time you have to get all your pieces working together. Eventually you have something that's not pretty but hopefully functional. That's just the real world.
“An idiot admires complexity, a genius admires simplicity” - Terry A. Davis
Holy C❤
theres other end to this too. simply using hacks, patches everywhere and creating bad code.
go for simplicity, not easiness.
do it cause its simple, not easy...
Reminder that what terry was talking about were things like _the linux kernel_ which are complex not because its designers were dummies but because they solve real problems that people have instead of being bedroom projects like templeos.
It's easy to keep your stuff simple when it's useless.
@@isodoubIet because certainly all products in the real world need to be overengineered. I suppose Terry can't have right opinions even when he makes """"""bedroom projects"""""".
You can admire simplicity (comparing any BSD or Mach or Inferno with Linux), you're aware of that, right?
Tom’s a genius
I don't think we love complexity as such, I think we love feeling like wizards. And a lot of the work is not wizardry, it's bricklaying and plumbing.
Edit: LOL just reached the plumbing part. Well then.
Shut up, we are wizards
... your comment reminds me of when i started to learn programming on my own and gave some comment on some fb group about posts of "spaghetti" code etc...
everyone tried to sound smart geniuses etc...
i just gace my input after what i think of high-level languages and scripting in general...
that 95% of time you're not a wizard, but a peon... ur just glueing APIs together... not actually making anything useful... so i agree.. Bricklaying is a good metaphor....
.. to me wizardry is more like... when my friend accidentally when drunk puts a parental control on his steam.,,. forgots what he used...
and then uses wireshark to do magic and brute force it in less than a day, without getting noticed or banned from valve....
that's wizardry to me
I need ma kick
I think if you want your self to be labelled as wizard then create some big shit like linux kernel like what torvalds did other wise just consider yourself soy dev and move on 🤷🏽♂️🤷🏽♂️
No, we like complexity. Makes is feel smart to know something most people won’t bother to learn. Not because it’s useful, but because we can feel smug about it.
My father warned me against getting into computers because you end up doing nothing but plumbing. I thought what does he know, as he had never owned a personal computer in his life. Turns he did know more than I could possibly imagine.
Yea laying pipes is my daily dream job
Love laying pipe 😮💨
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. - Gall's Law
"A complex system designed from scratch never works"
You can use formal methods to design complex systems and formally verify that they will work before implementation. Processor architectures, for example, or other complex hardware systems. Amazon also uses some formal methods for their distributed architectures and they manage to deliver massively complex working systems on schedule in time for re:Invent each year.
@@fennecbesixdouze1794 Surely processor architectures are a prime example of what was being talked about? 8086 was a hell of a lot simpler than x64! Modern implementations might well be done via formal methods and design software but they inarguably evolved from simpler working architectures.
@@secretchefcollective444Itanium and iapx432 say otherwise.
The complex system evolved from layoffs and new employees that have no idea what they're doing. Add to that lazy managers with no sense of leadership and you have the spaghetti code mess we have today.
I spend all my time on planning. And none of my time on development, or solving problems. I have accomplished nothing. Therefore, I have optimized for simplicity.
Zero bugs written, so success!
Man I got to stop working for tiny startups wtf 😂 what is planning
Me
One of the reasons why I enjoy working with trading exchange services is that we literally have no CPU time left other than what we use for business code and service reliability.
The only way to reach tens to a few hundred microseconds of RTT is by running the code with zero fat and waste.
What do you do?
We run the server/platform side at a securities exchange, like Nasdaq, NYSE, Euronext, etc.
don't reinvent the wheel, but lean on publicly available knowledge on how wheels are constructed instead of licensing the wheel factory for X dollars a month because you need 4 of them.
Check requirements for Wheels for Airplanes, Baby strollers, Mario Kart, Oil press and Python libs.
Yep. Don't reinvent the design for the wheel, but build it yourself.
@@parkourbee That is the exact scaling issue in this video. If your product uses wheels, but isn't wheels, don't turn it into two projects by trying to build your own wheels. Just buy them from an existing wheel expert and work on the real project. When the project is good and making money, then bringing wheels in house might be a good idea.
@@barongerhardt I agree for some things, but some wheels, like auth, often need to be fit specifically to your car. Other wheels, like analytics, can be self-hosted like with Plausible. And then of course there's npm install wheel.
@@parkourbee He says later in the video, not to take a the complexity and problems of a whole lib just for one short, easy to implement function. These as well as thin vs thick client are parts of the art. Early on, in almost every case it is better to buy as many solutions as possible. Then as things grow, pick the things that are causing bottle necks. Then comes the cost saving efforts, from easy to hard.
Simplicity enables speed. And more importantly, it enables the idiots who come after you to understand what you did so they don’t feel the need to tear it all down and rewrite it.
Without rigorous definitions, ‘simplicity’ and ‘complexity’ are just emotions. You _feel_ something is simple or complex
Previous job was maintaining a 15y+ old B2B app that had a postgres db for 20k users, ~1tb data. We had upgrade servers whenever Linux ran out of updates. For performance it was always "add index".
That title's kerning is a crime
radi cal simpu ci ty
It has to be on purpose, right?
@slicedtoad They also made Cheetos Lip Balm on purpose.
10000%
@@slicedtoad Doubt it, most people don't actually pay attention to typography besides choosing commonly recommended types.
It really bugs me when people don't differentiate between complexity and complication. (Admittedly, the distinction is kind of systems science jargon.) Complexity is when a few simple parts lead to lots of rich behavior. Complication is when you have a giant pile of exceptions. Lambda calculus is complex but uncomplicated. HTML is uncomplex but complicated.
This comment needs to go higher.
I think you are correct. Complexity is about emergence, aka the result is bigger than the sum of all parts.
People love complexity. Looove it. Relish it. I have a colleague who's constantly stressed out and complains about convoluted legacy solutions. Yet he excels in designing the most complex solutions where seemingly simple tasks can grow indefinitely in lines of code. And he fights me whenever I point out that this or that could be made much simpler or that he shouldn't implement something until it's actually required. Most developers I've worked with has been like this to some degree. They love being "smart", love introducing new design patterns or frameworks or a fancy nosql technology or establishing message queue contracts or refining some foreign key constraints. And they loooove discovering "problems", that is hypothetical issues that nobody has experienced yet. I'm sick of it.
Dude I wish you were on my team. I have the same arguments all the time. Simple SQL database and java or c# or go or some other reasonable back-end language for a back end api, then html/css/js in static files for your front end, and your first 10K users will be fine. If you are fortunate enough to need to support more than 10 thousand users, you will find out that the bottlenecks are not where you thought they would be, and you will be in a much better position to design a more scalable solution for your particular needs.
@@freeideas thx u. I work in a small telco. We have some 70,000 users (depending on how to define it), but even with this simple stuff still works wonders. Sometimes the amount of code exercise some of these "clean code" dudes produce is amazing. A nightmare example is that we needed to use a third party API to get a company credit score. A simple REST API that should be perhaps 8 - 10 lines of code: make an HTTP request, check the response code, unpack the JSON, perhaps cache it for some time. Simple stuff, right? Wrong. We only had use a single endpoint from this API, but some genius thought "why don't we implement a clean internal interface for all of the endpoints exposed by this API? We could use it in some future projects". The stupid thing ballooned to 3,000+ LoC across dozens of files, with inheritance trees, interfaces, etc etc.. with a full unit testing suite.... for doing a simple HTTP request and unpacking the response.
True. Many times it's Resume Driven Development. Even if the project doesn't really need it, they'll bring unnecessary stuff to have "professional experience" on them to pad their resumes.
They also typically love whiteboard masturbation and/or complicated abstractions that cover a wide variety of usecases (most of those usecases never even arrive, or have very simple alternative solutions).
Developers love complexity lol. They want to "grow", never content with building a simple solution that just works given the project scope. It hurts my soul seeing simpler solutions getting "scalable" and "dry" by them when there wasn't any need for that scalability or dryness.
But they're the ones getting pats on the back for being "productive" (producing more code, when most of it isn't even needed) and they also get to make their resumes padded which helps them in job hunts for higher salaries.
Although I generally agree with you, I recently had a problem with this statement:
"And he fights me whenever I point out that this or that could be made much simpler or that he shouldn't implement something until it's actually required."
Funny thing is, I implemented a thing that is not required yet, and is still not required. However, I spent this whole week, editing, like, tens of functions just so I can have this one 'seemingly simple but required' thing working, that I didn't think of in the first place.
I think this is one of the 'hard problems', and that it get's easier with experience (never solved).
I even saw 'TODO:'s in some of these functions that I wrote myself.
@@ThaSPAWN it's part experience and part Texas sharpshooter fallacy. Without fail, every one of these premature abstractions and preemptive implementations done by my colleague has turned out to be hindrances rather than actual help.
Incidentally I lost my temper with him yesterday. He was supposed to implement a simple set of messages to be routed on an AMQP channel. The messages should tell the router component where they should be routed. You'd think that should be a simple task of defining an interface with getExchange and getRoutingKey, having each of the 10 or so message types implement this interface and be done with it? Wrong. I'm looking at two levels of inheritance, a special configuration class, and a configuration dictionary. I mean ... Why? Why on god's green earth would you do something like this? I confronted him that this was way too convoluted and complicated. He just replied, and I'm not paraphrasing, "I like this level of abstraction. This is my coding style. Not everyone likes simple code like you do.". I'm not making this up.
We got a new project at work. The business logic is about 120 lines of python parsing code slapping that stuff into an SQLite Database that gets packaged with a go app into a container. The business logic is essentially a few lines of SQL.
The frontend however is an Angular app that has a few thousand lines of typescript already...
SQLite is about 116k lines of code, Go is about 167k lines of code, and python is about 154k lines of code.
So your backend project is actually about half a billion lines of code.
@@fennecbesixdouze1794 what a poor take from you.
I'd bet $100 that the front end could be written with fewer lines of plain old HTML/JS/CSS in static files, than with Angular/React/Vue. With cherry picked use cases, these frameworks save you a lot of code and complexity. With real world, these frameworks force you to write a monstrosity.
@@fennecbesixdouze1794 If you count lines of code in the back end components (even in the COMPILER!), then we have to do the same thing for the front end. The Angular app runs on a web browser, most of which are many millions of lines of code, and the TS compiler is about 250K lines, and should we count the javascript engine that the TS compiler runs on? So if you want to compare lines of code this way, the front end is still enormously more.
@@fennecbesixdouze1794Right, then let's also count lines of code for operating system you run on, IDE, git, git server, server hardware code and literally everything that is somehow involved
I am working on a project that has 4 Teams totaling 25 people. We have 5 Java microservices, 8 AWS lambdas, a mongoDB for main storage of data, 3 AWS SQS queues, 2 nextJS frontends, redis for caching, dynamoDB for storing some other random stuff and 12 AWS SNS topics for what is essentially a CRUD app that sends out notifications when something happens. I have no clue how we ended up here. The local dev environment, building and shipping is hell.
"Simplicity taken to an extreme becomes elegance"
-Jon Franklin
I work at a company that is having trouble pushing its monolith app further to service our clients. We have 5 developers and I'm pretty sure ownership doesn't have tens of millions of dollars of runway. The problem is not that our user base is so large (it's on the order of tens of thousands), but more that we tend to get pinched really hard at certain times and can't scale for momentary needs. We also have an enormous amount of data to keep track of despite the small user base (and it really matters for our users, we're not just hoarding data). Poor architectural decisions that evolved over many years also plays a significant role.
Enormous in the GB?
@@haydenflinner like gigabytes? yeah if not larger. hundreds of tables, hundreds of millions of rows in some, query times in the minutes in some cases, far more factored out tables than there really should be ("single source of truth" taken way too far)
The problem is developers buying into the current thing no matter if it fits their project or not.
Why does a CRUD app for a handful of users need to have a bunch of microservices? Why not a modular monolith?
The predominant dogma in the developer community doesn't even allow posing that question.
Mock them with logical submission until they trigger themselves and start throwing ad hominem.
Often, stack complexity is the result of hiding company politics in the codebase instead of effectively solving them in a meeting.
this!
Definetely. Status games and lack of skill masking by bluffing it up with buzzwords and cargo cult tech.
Simplicity wherever you can. Complexity whenever you have to.
this has the same problem as "use the right tool for the job"
@@lifelover69 the word you're looking for is "aphorism"
Be ever deleting
Agree with Prime, apps are more complex nowadays. I remember trying to write partial page reload by hand and it was so tedious and so annoying and bugprone, that I hand rolled my own library to handle it. I couldn't possibly imagine working on a website like that in a large organization doing it by hand. Nothing would ever ever work for longer than a day.
As a dev, I feel pleasure from refactoring code to one-liners
Anything can be a one-liner, "join-lines" is not a refactoring move.
@@FrederikSchumacher Who said anything about "join-lines"?
@@FeLiNe418 It was a polemic overstatement. He was hinting that many things that could be on one line shouldn't.
@@vaxrvaxr I don't count stuff like
int x = 1; String text = "blabla"; long n = 1000;
as a one-liner.
@@vaxrvaxr Something like that. I did intentionally misunderstand and oversimplify my response to @FeLiNe418 in an attempt of humor. However the statement could be expanded into a discussion. What is a one-liner? What is refactoring? Was the intention to communicate "radical simplification" by removing code? Consider taking 200 lines out of a 300 line mess and refactoring it into a separate function, the statement would be satisfied, however the phrase "refactor into one-liners" would carry different meaning. Consider removing a home-rolled caching solution and replacing it with a common third-party library, this could be considered "refactor into one-liners". Does any of this create joy? Is joy so created a relevant KPI? Why not?
I read that as Radical Stupidity. This happened because I have heat induced dyslexia.
Simple minds think alike.
I wouldn’t be surprised if the name of that font _is_ Dyslexia. Wtf is that spacing?
“radical stupidity” 😂
To be fair the keming was also pretty radical
Most people that go into engineering fields (of whatever sort) _love_ complexity. Unfortunately, engineering is the process of _removing_ everything that is not necessary to achieve the goal. Obviously that is incompatible with flagellating yourself over how superior you are for being able to build and figure out super complex systems, so we end up with a lot of bad engineering.
As backend engineer in a small agency, for me radical simplicity is choosing and implementing the proper cloud services to solve problems. But i always deeply learn about them and have at least one fallback FOSS product which can do the same on-prem.
Treating PostgreSQL and PHP as golden hammers sounds horrible.
I built a major project for my last company in Django with Alpine and HTMX to handle any frontend reactivity needed, including the chat feature it needed. Daisy for UI. Built in Django features for as much as possible before relying on something else. I even kept it as a SQLite DB. I wrote only 16 lines of Javascript.
When an engineer working on another project asked why I went with that stack, I answered that it was stable, battle-tested, simple to maintain, and that by the time we scale past its ability to keep up we'll have the money for a team to build at the level of complexity required for that context. Apparently, that was the right answer. Ha, he told me if React had been involved at all, I'd have probably been fired.
They ask after the fact. And based on that they fire you? Doubt…
could you explain why he told you that about React? I'm about to start a major project using Django and planned to use React for the frontend. But since it's my first major web dev project and I'm using it to basically learn and decide on a stack, I'm curious to know why React was a bad choice there. Django is a must cause I'm doing the heavy lifting in python.
Did you really say Alpine and HTMX are "battle-tested"?
@@stefanalecu9532 I was specifically talking about Django. I should have been more specific. HTMX is as reliable as the templating engine you run it on.
@@stefanalecu9532 with this setup the app is server rendered, quite unlikely that you run into an actual htmx bug, and even less likely it has any breaking effect.
Honestly I think "The Lean Startup" should be a must read for developers, and use the same lean principals for development. Goes right to the point of using frameworks for "future" requirements when for example you have to few users and the data is too small to even need to cache anything.
96% solving problems around what we built. Our frontend is in Elm, and we somehow still managed to spaghettify it. That means, excessive use of generics, message value transformers, closely coupled library and application (application specific logic in library!), and nonsensical naming. It took a month for our team to remove a field from a form.
I didn't notice exactly when it happened, but congrats on the 500k!
This might end up becoming the main channel at this rate.
Haha lol
I call it "showing the brilliance". You try to quickly be as useful as possible, even if that means helping somebody else solve a problem and making them look good. Works best when you're not trying to be a manager.
I believe the problem is lack of modularity. Effective solutions seem to be founded on the principles of generalizing components (aka parameterizing output with input) and composing those pieces into a system, which can recursively be parameterized and composed into more versatile tools. And problems can be thought of as the dual/converse: we often start off with one complex problem and then learn to decompose it into many simple problems.
Solutions can be thought of as a graph structure where some nodes are big/versatile tools that can be related to their small/specific sub-tools. Problems are also a graph of big problems related to their sub-problems. Then an engineer's goal is to relate certain sub-problems to certain sub-solutions to complete the problem-solution graph for a certain use case (collection). We can think of the solution side of the full graph as the code library / framework / toolset and the problem side as the domain. Having this modularity with only minimal interfaces between components of problems and solutions allows rapid understanding, change, extension, etc.
It feels like there's a lot of good sentiment sprinkled in with examples that aren't the best just because it's that all they know. If you're in a box all your life, then you're not too familiar with what's outside of it, and that's if you even recognize that the box exists.
Many engineers would rather build a cool new tool than solve another boring app requirement. Hence tool explosion and complexity
If you're not sure whether you can use old technology, consider that your hospital probably only changed their front end away from Visual Basic in the last year or two (if you live in the us).
“Micro-lith” is the best approach IMHO. Declare your managed micro-services in IAC such as CDK. Treat it as one small codebase. Basic pipeline deployment.
I work on a custom operating system for edge computing and the feedback cycle can be very long. For some stuff we have python modules so we can run it on a cluster and iterate more quickly there. But to actually test how it interacts with the rest of the system, we have to run a test with the running OS. Feedback takes 30 minutes to several hours. It is unclear how we can ensure that a cluster running the OS works as intended without actually running it on a cluster
Radical simplicity works well if your project is straightforward and won't need changes, like many mechanical and electrical engineering projects where once it's built, it's done. But not every project is like that. For complex systems, you can't just assume the design is final. That's why we focus on modularisation and sometimes overengineer. Sure, this adds complexity, but any experienced engineer knows it's worth it. Modularisation isn't easy, but it allows for flexibility and future updates. And there's nothing wrong with over-engineering when done right, you learn to judge when it's necessary with experience.
You also have to accept that customers often don't know exactly what they want at first. It’s part of the job to help them figure that out as you go.
When he talks about the focus at about 13:20 it reminded me of a lot of game dev ui. That stuff can be hard for rpgs to figure out
I started with QBasic too, in high school programming class. My first "game" was a Final Fantasy clone, binary loaded sprites (difficult in basic but fun), and my "game" spanned several floppy disks, lol (very unoptimized). I was ahead so I learned Dark Basic, which was worlds of fun back in the day. First game with it was a simple flight sim, using two (top/bottom) randomized 3D Metrix, with collision detection; you hit, you die (simple game over message) and you'd start again (it was actually quite addicting to play, and it was like one page of code). Simple syntax but you could program 3D games, and it had game controller support built in. It was amazing! Brings back memories. Those were the good 'ol days, lol.
Re: 19:53 and the Postgres-as-everything argument.
"Why are you committing to such intense stuff, when you just need something that is so simple?"
Because they are in job descriptions and (I'm guessing) might come up on an interview.
Tbh, I like this idea of starting with a more foundational technology like Postgres and letting yourself "grow" out of it into more specialized products like Redis or Elasticsearch. But I also feel that nagging pull of "but what if it comes up in an interview). And I'm not someone who can learn the basics of a tech from docs and be confident I can answer questions in some interview in a few weeks or months. It will fall out of my head unless I'm touching it pretty consistently.
I'm fortunate that I am (fingers crossed) still employed, but if you are in this position and job searching without money coming in, yeah, I definitely understand feeling pressed to learn every new hotness if I see it in a relevant job description.
I'm an "invent the wheel" kind of guy personally, writing a game with pygame has been extremely informative and I'm loving the process, there's so many little ways to optimize
the urge to make system complex comes from the need of making system more configurable, extendable, quick to add similar features.
But the problem is we devs dont always see when we need to do something once and forget about it and when we need to do actual optimization.
Leading us into loop of premature optimization.
Love these videos... when i have the audio playing in bg while working I think I'm listening to Rick from Rick n Morty which gives the content even more credibility. Just need to belch n burp every now and then.
4:27 The sites did not get more complicated. MapQuest and Google Maps is a great example of the old way vs the new way. MapQuest worked fine, and Google Maps made it better at the expense of astronomical cost and complexity. MapQuest could have been progressively enhanced to do the exact same thing Google Maps does today on that old ass tech. It would be way less complicated too.
37:41 He seems to be old school. Perhaps what he meant by Scrum is the old agile way (agile manifesto), not the enterprise meeting storm it has become.
I agree, the agile manifesto has been bastartised by business, the idea of breaking down a project and iterating as you go works really well if run properly. Then again I know a ton of devs who complain about even while run agile projects because it apparently breaks their flow. My biggest push back to this is always your flow means Dickson if the product delivered isn't what the client wants, so take the pain early and by the end of the project everyone will be on the same page with what has been delivered.
Radical Simplicity - "Bro had diarrhea" dang, that some radical sh*
Flip not holding back 🤣
Hasura is written HASKELL! I remember when you asked for one example of a real world program written in Haskell, here it is. They are also a billion $ unicorn company. Food for thought...
Sorcery was forbidden because it was trying to go a shortcut instead of doing the work. If you think of your self as a coding wizard, then likely you just want to npm install your way through the problem you are solving or bowing down before your Gippety idol instead of doing the work YOURSELF.
This video and article touched my soul. I have come to a similar conclusion only recently.
Also I had to laugh out loud several times 😆
12:15 → Gold! Pure gold!
Simplicity is the ultimate complexity, that's my definition of elegance
The kerning on that Radical Simplicity logo text is terrifying
probably why I don't like using frameworks unless absolutely necessary
makes you learn how things actually work and keeps things manageable
I'm not here advocating for building an entire database from scratch, but maybe stick to using just one _(or possibly two, depending on the usecase)_
many apps can essentially just be a front-end to some database
This whole article touches my soul. Completely off of React since 2 years. Svelte is the way for me for SPAs and vanilla JS with sprinkles of Alpine JS if the case suits it better.
Btw, what is the black board paint like tool Prime keeps using? GIMP? Can't be sure as the UI is so teeny.
99% confident that it’s GIMP
>svelte
>not having to compile shit
>that not being complex
Teachlead had a great joke. I remove any code that doesn't spark joy. My codebase is now just empty
Man, I was a webdev from 2004 to 2013ish, when I became chronically ill. It’s so cool to hear you name all the stuff that used to be normal to me. Sqlite, postgres, lucene. I get the impression everything is just frameworks stacked on top of each other nowadays. I absolutely loved the feeling of starting a project with a clean slate. Just an empty db and base project directory. Starting by creating a crud layer, some basic mvc functionality and maybe a js framework, like jquery or mootools. Man, those were the days! 😊
I don't know how Uncle Bob is going to feel about being considered the enabler of the agile methodologies deprecation.
11:33 definitely a valid argument. An app I’m working on now is just a tool to execute calls to another API. Now there is a need to make it easier and automate the tasks but it’s nothing a script can’t do. In fact that’s how it started. Now I’m just making it persistent with scheduled jobs.
I love when I can get my head around complexity, especially when its clear that there isn't an understanding of the complexity around you, or if what people think they understand about it is not correct and that is preventing a more efficient system. That's what makes coding fun, having your understandings tested as you plow through the details until it comes together. And when you get surprised and have to adjust your logic or code when things don't turn out working quite like you thought, you learn even more about your own ability to mentally model things, and get better at intuitive modeling (sort of... your understanding reflex?) for the next complex problem.
For Postgres vertical scaling makes sense, but for stateless horizontal makes more sense. With vertical scaling each scale event causes downtime. With Postgres this is usually fine depending on service level objectives and you can retry queries to mitigate. With stateless workloads horizontal scaling is very easy, cheaper, and has way better uptime of course.
There are also languages that poorly scale vertically, like Javascript.
“I want to flex on fancy projects rather than fancy code and configuration. That's why I'm a Gopher.” -- Bill Kennedy
Embrace the complexity of simplicity. Thank you for the content.
that's why python modules exist - to introduce radical simplicity
I seen a video streaming site that litterally was just 3 files:
1 HTML
1 CSS
and 1 JS file.
No backened and it worked without any bugs.
but there is no react and typescript and virtual dom and effects components whatever is there?
Serving 3 cat videos?
@@stefanalecu9532 serving free movies and tv shows including shows that come outbon streaming services on the same day
@@theairaccumulator7144 its just plain javascript. No typesrcipt, no react
@@stefanalecu9532 you know those free movie/tv show sites? Its exactly that
honestly speaking, I have to kind of disagree with this because I've spent most of my career, literally years, solving problems around performance constraints. which is outside of your bubble that you drew and was all done quote on quote in the pursuit of simplicity. I've really often found that the simple solution while it gets you out the door quickly it always comes back to bite you in a incredibly expensive way. I'm talking like spending millions of dollars kind of thing.
I'm interested in whether you're conflating simple and easy. I've found that simple things can be more easily refactored, and are thus less expensive to correct. Simple can be hard to achieve. Easy, on the other hand, often means coupling with something that can eventually fight everything you need to do. Regardless, you're sometimes forced to make decisions before you know what you need, and those mistakes can be expensive if the decisions were based on very wrong assumptions. Other than that, I have never experienced anything where reducing complexity and dependencies was not a good strategy to fixing something terrible. Can you give an example? (On a side note, it's called 'quote unquote')
@@Muskar2 I've been meaning to write a blog post about this actually. think I'll spend some time today/tomorrow doing it and see if prime is interested in covering it.
@@hi117117 do it and reply when you do it.
Inherent complexity vs. Accidental complexity.
Accidental complexity = technology complexity * technology m*sturbation.
We are very good at j*erking off!
Frameworks, Kubernetes, Microservices and other stuff is created to solve problems. Problems that you get by trying to be "simple" and raw digging without frameworks.
This is basically what Vertical Slice Architecture is advocating ;-) Keep it a monolith BUT make it simple but make it easy (or at least, easier) to pull components out if certain components become a bottleneck.
Postgres is also super simple to use in CI. You can pretty much copy a template DB as fast as a file. It's pretty good. Haven't tried doing this with sqlite, but it's probably even better if it fits your needs.
In 2001 I worked on web application that had dynamic UI - loading data from server and building UI on client, all state stored in DB. No React, no Angular, just plain vanilla JS, and still it worked. Internet Explorer compatible! Industry has added layers of complexity since then... for nothing. Users or businesses didn't get much out of it, but developers gained pay rise :) IT accounted for 10% of corporate spending in 2020s, and it was just 3% in 2000s.
The part where you said raise your hand if you have more micro services than users killed me… too relatable
typescript is super rich, but its biggest flaw is to allow multi type for a single variable. this is the root of complexity that developer should not do
I'm a bit confused about the Netflix tv app around 13:50. Why is thr focused not as simple as a stack?
That vertical scaling bit got me 😂 pretty good! 22:39
Congrats on reaching 500K. Let's go!
Going vertical does not get you high availability. There, enough said (JK, here's more. I used to vertically scale on aws us-east-1. Things were great. Then aws networking and Ubuntu plus docker destroyed us. What I mean is, aws had a network failure affecting our availability zone. We are forced to live in horizontal scaling because business demands that there be masures in place against this sort of thing. Uptime matters. My application supports doctors around the world. When should I have down time? I can't. My performance needs aren't huge at all, but I can't be down. Ergo, I have 3 VMs across AZs. I'm not doing this for fun I'm doing it because I have to.)
Scaling horizontally and availability/redundancy are not the same thing. You can scale vertically and still have multiple availability zones / backups.
"I spend all my time building the problem." - ThePrimeagen (and every other dev)
A marketing site should use something like Astro. This is because you almost definitely don't want to ship large amounts of code to the client in order to show the site. You want primarily HTML and CSS shipped.
React Server Components are the way to do Astro without doing Astro, except not as good for static content.
16:42 I also worked at Workiva, though from 2017-2020 (you can guess why I left based on the date). It was mountains of complexity, especially on the frontend. That being said, you quickly learn which mountain trails you enjoy and which mountaineers you enjoy climbing with. 😄
For my start-up, im still bashing my head against too much complexity, but because I'm not a developer myself, i opted for well known technologies that are well documented and for which there are plenty of devs. Managed digitalocean postgres and redis instances, droplets running Laravel. Unfortunately a react frontend, which i now regret.
I now wish i had just used wordpress for it all the way and just created drag and drop custom fields instead, but i still feel like i dodged a massive rocket
What was so bad about React?
Trying to make things simpler is a huge challenge. If this was about being challenge, pick that one. Caring about maintenance, developer experience, code simplicity.
Jonathan Blow is putting these very similar and familiar sentiments into a programming language's ethos he'll hopefully release soon. Before Silksong or GTA6.
Organisation are also pretty bad at determining when stuff should run on servers at all. This is especially prevalent in mobile apps e.g. why would I ever want to generate thumbnails for pictures on my server, if it's being uploaded from a device that is literally build to excel at this kind of thing? Just write the damn code on-device. You aren't going to kill the battery. It's fine.
It's simple for monolith situations. Instead of trying to start with some kind of micro architecture trying to solve problems you don't have whilst introducing a bunch of problems you didn't envisage, just run monolith - then one day a portion of that monolith will be better served not being part of the main stack due to mass-usage or heavy computation, or simply that it doesn't need to run immediately like sending an email - so pull it out and put that into it's own service with a message queuing system.
Rinse and repeat
can you look into wasi runtimes and the wasm abi changes. I'd really like to see your take on it.
I just use HTML, CSS, jQuery and PHP with phpmyadmin.
So in actuality, you're using HTML, JS, CSS, jQuery, PHP, MySQL or MariaDB, phpmyadmin, Apache or nginx, and _hopefully_ some kind of stable Linux distro underneath.
I'm saying "hopefully" because otherwise you're using either a rolling-release distro or Windows to host a website, and I'm not sure which is scarier.
Just because modern magic hides the complexity of your setup, doesn't mean said complexity isn't ready to ruin your day when you least expect it.
Gotta be aware of your setup's true complexity, no matter how simple it seems compared to the alternatives, or you'll end up with a server full of footguns.
@@genxer1824I use nixos unstable btw
@@genxer1824 i think youre simplifying the mountains of complexity that is built on top many of the same features you mentioned. Its not like these arent included in modern stacks, theyre just hidden, along with all of the added build step complexity and redundant client side logic like auth, routing, etc.
Jup, software is all layers, and this will always be the case unless you want to write code with zeros and ones.
confirming when web app is not so big that can reload page almost instantly it's not worth the complexity with SPA-s. I work in university and we developing a web app (database for all data related to education processes) and it was started with vanilla js, php on server and a single database. later we added vue components for some more complex UI controls, but not the entire page (mount just in small partrs of the page) I was actually surprised to see same approach later somewhere (maybe Astro) called "islands of reactivity". it works fast and maintenance is easy (with our limited human resources) because code per feature is not big
The Great Tom laughs at simplicity. In fact, he wants a system that explodes when you put comments in the code.
All my new projects get written in PHP now for speed and simplicity. If, after a few days, it seems like some advanced stuff is needed, I'll rewrite in something else, but it's rare that it happens. Because some code has already been written, it's easier to think "Do I *really* need that thing though?"
The same thing happens on the factory automation industry (and I'd argue that in many other fields this is a thing). A standard is set, the standard is used and abused beyond what it was made for, the standard is updated to work better within those wildly expanded requirements and that ends up validating the hacks and convoluted solutions. Just look at how many "naming conventions" exist for sensors and other devices on a factory because at some point someone decided that it'd be a good idea to give the smallest size possible to a naming field, and those conventions have been kept up for backwards compatibility.
So you're telling me that the hardware component naming garbage was completely avoidable?
It's funny, I'm spending this time working on SQL serializers for a Django server that will then send slightly differently structured data to my React FE to enable new features so that I can start building the thing I set out to build 4 days ago.
👏 agreed so much with everything covered, nodder city over here!
Learning Python for work, and ended up having to make a program far beyond my skill level. As Prime stated, I just tossed it together using something simple, that would work, figuring I can go back and make it pretty later. As long as it works, that's all that matters when it's crunch time I think. I am looking forward to ripping into it though, and seeing what new things I can do to accomplish the same goal
i remember we migrated from AngularJS to NG6 large enterprise app, and it went for 2.5 sec full load to 12 :D
I've been taught and my development team always employ this method: Start simple and optimize only when needed.
"If you have more microservices than users press 1" man you did not have to slap that hard
Problem is, we try to build illusion that everything happens at client's browser in real time, while it happens on the other side of globe and sometimes take substantial amount of time. Which is impossible. And bigger the discrepancy is, bigger chance illusion breaks.