Radical Simplicity

[@codyoftheinternet]

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).

[@patrickshepherd1341]

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.

[@zeppelinmexicano]

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.

[@jeffwells641]

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]

Do people in the US refer to colleges as school too?

[@patrickshepherd1341]

@@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.

[@salvatoreshiggerino6810]

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.

[@warrenarnoldmusic]

Yea laying pipes is my daily dream job

[@stephanschmidt2334]

Ah so this is where the traffic for my website is coming from :-)

[@jaideepshekhar4621]

Hey, nice read!

[@vilian9185]

o7

[@thomasbuss]

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

[@ultimaxkom8728]

Where's the explanation for that Scrum take? Can't see it.

[@Turalcar]

Congrats on being PrimeDotted

[@RT-mn2pb]

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.

[@JorisGriffioen]

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.

[@theinsane102]

Shut up, we are wizards

[@Microphunktv-jb3kj]

... 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

[@XDarkGreyX]

I need ma kick

[@mazharansari7813]

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 🤷🏽‍♂️🤷🏽‍♂️

[@JohnSmith-op7ls]

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.

[@kahnzo]

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.

[@Kane0123]

Zero bugs written, so success!

[@ameddin73]

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

[@fennecbesixdouze1794]

"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.

[@secretchefcollective444]

@@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.

[@georgerogers1166]

​@@secretchefcollective444Itanium and iapx432 say otherwise.

[@xxvmvxx]

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.

[@postblitz]

Check requirements for Wheels for Airplanes, Baby strollers, Mario Kart, Oil press and Python libs.

[@parkourbee]

Yep. Don't reinvent the design for the wheel, but build it yourself.

[@barongerhardt]

@@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.

[@parkourbee]

@@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.

[@barongerhardt]

@@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.

[@noredine]

That title's kerning is a crime

[@GackFinder]

radi cal simpu ci ty

[@slicedtoad]

It has to be on purpose, right?

[@Millenimorphose]

@slicedtoad They also made Cheetos Lip Balm on purpose.

[@taylorjohnsonct]

10000%

[@taylorjohnsonct]

@@slicedtoad Doubt it, most people don't actually pay attention to typography besides choosing commonly recommended types.

[@onegamingmoose]

“An idiot admires complexity, a genius admires simplicity” - Terry A. Davis

[@martijnb3381]

Holy C❤

[@duckydude20]

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...

[@isodoubIet]

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.

[@stefanalecu9532]

​@@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?

[@whimahwhe]

Tom’s a genius

[@dschledermann]

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.

[@freeideas]

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.

[@dschledermann]

@@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.

[@Dipj01]

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.

[@julkiewitz]

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.

[@MatiasKiviniemi]

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".

[@ZeroUm_]

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.

[@mauro--1521]

What do you do?

[@ZeroUm_]

We run the server/platform side at a securities exchange, like Nasdaq, NYSE, Euronext, etc.

[@Mooooov0815]

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...

[@fennecbesixdouze1794]

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.

[@tonimaunde]

​@@fennecbesixdouze1794 what a poor take from you.

[@freeideas]

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.

[@freeideas]

@@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.

[@cucumberwithketchup]

​@@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

[@AG-ur1lj]

Without rigorous definitions, ‘simplicity’ and ‘complexity’ are just emotions. You _feel_ something is simple or complex

[@JoeJoeTater]

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.

[@ultimaxkom8728]

This comment needs to go higher.

[@thebrutaltooth1506]

I think you are correct. Complexity is about emergence, aka the result is bigger than the sum of all parts.

[@SimGunther]

"Simplicity taken to an extreme becomes elegance" -Jon Franklin

[@hamm8934]

Often, stack complexity is the result of hiding company politics in the codebase instead of effectively solving them in a meeting.

[@fireprincezuko]

this!

[@AnonymousAnonymous-l2i]

Definetely. Status games and lack of skill masking by bluffing it up with buzzwords and cargo cult tech.

[@Griffolion0]

Simplicity wherever you can. Complexity whenever you have to.

[@lifelover69]

this has the same problem as "use the right tool for the job"

[@Griffolion0]

@@lifelover69 the word you're looking for is "aphorism"

[@trappedcat3615]

Be ever deleting

[@IdkMaybeShawn]

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]

Enormous in the GB?

[@IdkMaybeShawn]

@@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)

[@solii01]

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.

[@nickmurdaugh9856]

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.

[@avwie132]

They ask after the fact. And based on that they fire you? Doubt…

[@hola_chelo]

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]

Did you really say Alpine and HTMX are "battle-tested"?

[@nickmurdaugh9856]

@@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.

[@RogerValor]

@@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.

[@LearningLife77]

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.

[@electronicXtacy]

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.

[@EdmondDantèsDE]

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.

[@AnonymousAnonymous-l2i]

Mock them with logical submission until they trigger themselves and start throwing ad hominem.

[@Exilum]

I didn't notice exactly when it happened, but congrats on the 500k! This might end up becoming the main channel at this rate.

[@Kane0123]

Haha lol

[@KazmirRunik]

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.

[@chudchadanstud]

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.

[@KH40T1C_yt]

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.

[@JGComments]

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.

[@principleshipcoleoid8095]

I read that as Radical Stupidity. This happened because I have heat induced dyslexia.

[@vaxrvaxr]

Simple minds think alike.

[@AG-ur1lj]

I wouldn’t be surprised if the name of that font _is_ Dyslexia. Wtf is that spacing?

[@me_12-vw1vi]

“radical stupidity” 😂

[@ceigey-au]

To be fair the keming was also pretty radical

[@FeLiNe418]

As a dev, I feel pleasure from refactoring code to one-liners

[@FrederikSchumacher]

Anything can be a one-liner, "join-lines" is not a refactoring move.

[@FeLiNe418]

@@FrederikSchumacher Who said anything about "join-lines"?

[@vaxrvaxr]

@@FeLiNe418 It was a polemic overstatement. He was hinting that many things that could be on one line shouldn't.

[@FeLiNe418]

@@vaxrvaxr I don't count stuff like int x = 1; String text = "blabla"; long n = 1000; as a one-liner.

[@FrederikSchumacher]

@@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?

[@dmccallie]

Many engineers would rather build a cool new tool than solve another boring app requirement. Hence tool explosion and complexity

[@livingfreely]

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.

[@rns10]

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.

[@kaheahendrickson5155]

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...

[@sirgermaine]

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).

[@CoenBijpost]

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! 😊

[@gorlug]

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 😆

[@pythonBlender7]

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.)

[@stefanms8803]

Scaling horizontally and availability/redundancy are not the same thing. You can scale vertically and still have multiple availability zones / backups.

[@AstonishedByTheLackOfCake]

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

[@h.i.sentertainments8580]

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.

[@schism15]

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.

[@streettrialsandstuff]

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.

[@MrJoefinisher]

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.

[@JoshuaBlackmon]

The kerning on that Radical Simplicity logo text is terrifying

[@the42nd]

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.

[@blackbriarmead1966]

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

[@PhaizKannon]

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.

[@YoungGrizzly]

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.

[@riverm5889]

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

[@webkinskid]

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

[@jankucera8505]

that's why python modules exist - to introduce radical simplicity

[@innomin8251]

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.

[@JorgeHernandez-vs8jw]

Embrace the complexity of simplicity. Thank you for the content.

[@hooch912]

Radical Simplicity = Naive Simplicity. Why use a database? Why not use flat files? The reason is because you gain experience and understand the pain points you will encounter in advance. Having basic infra in place when you start is going to save you time in the long run. Radical simplicity feels like an excuse for radical laziness.

[@thngzys]

I love the point about having to bake everything INTO React. That's exactly the problem we faced in our enterprise application and it's absolutely stupid. Wanna change your business logic? Ok, crawl through a dozen components and make sure you update the store correctly. - Oh look, a bunch of tests just failed because you changed 1 business rule. Absolute trash. I love working with React, but I hate how it forces you to bake shit into it's structure. With that said, we're currently spending so much time extracting all that crap into a standalone module, then solve that reactivity elsewhere. So much simpler fixing a small module that's highly testable and doesn't depend on anything UI, than changing an entire branch of a years old DOM tree. kzbin.info/www/bejne/rpmQmoB4hL2fbK8si=lSO7JQSHjKhhxsQZ&t=828

[@huggingcat]

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.

[@hi117117]

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.

[@Muskar2]

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')

[@hi117117]

@@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.

[@l.piekha100]

@@hi117117 do it and reply when you do it.

[@antonioporrua8428]

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.

[@jamillairmane1585]

That vertical scaling bit got me 😂 pretty good! 22:39

[@MrSofazocker]

Radical Simplicity - "Bro had diarrhea" dang, that some radical sh* Flip not holding back 🤣

[@tsh4k]

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.

[@kriffos]

There are also languages that poorly scale vertically, like Javascript.

[@shadowsir]

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.

[@justabanob_2]

The part where you said raise your hand if you have more micro services than users killed me… too relatable

[@mikeicon8488]

MySQL, PHP, vanilla JS is all you need for most projects. Async is unnecessary for many sites and this is what adds a ton of complexity for no real reason.

[@EvanMildenberger]

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.

[@technocidal]

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.

[@dontdoit6986]

“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.

[@orionh5535]

Teachlead had a great joke. I remove any code that doesn't spark joy. My codebase is now just empty

[@BlackThorne]

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

[@ivanfoofoo]

What was so bad about React?

[@npc-drew]

Congrats on reaching 500K. Let's go!

[@matthiaslangbart9841]

“I want to flex on fancy projects rather than fancy code and configuration. That's why I'm a Gopher.” -- Bill Kennedy

[@begginercoding.3919]

I don't know how Uncle Bob is going to feel about being considered the enabler of the agile methodologies deprecation.

[@kahnfatman]

Radical simplicity leads to Simple Radicalism 😊 Prolog can analyze grammatical structures in human language like German.

[@stevenpartridge8215]

The end of the article, scrumm and list of languages, is just SEO spam. Good article before that though, thanks for sharing

[@KrisVuk]

I can't tell you how many times I've read articles like this or had discussions as such. Complexity comes in different shapes and flavours, and sometimes (as reality would have it), you have to embrace it. Some systems really do require multiple layers of complexity, but that complexity is managed by abstraction - not removal. If you remove the layers, you'll end up having a system that is lacking in some way (as is often the case). This could be flexibility, scalability, compartmentalization, performance, etc. I absolutely agree that complexity needs to be minimized, but no lower. Radical simplicity can easily be taken to an extreme where the problem you set out to solve gives way to a beast you can no longer manage at scale, or change as easily as you might hope. Example: Redis may not be here because someone wanted to be cool. It might be there because customers needs extremely fast read-access to what is likely a very hot storage layer and doesn't want the transactional cost of reading from Redshift, S3, Postgres, or whatever.

[@billyhart3299]

congrats on 500k bro

[@judgewest2000]

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

[@GackFinder]

I basecame while watching this video

[@AmirHosseinHonardust]

I like the sentiment. I don't like the implementation. The idea is a good thing to strive for. But the suggested tech stacks on the site suggest very much personal branding. Not simplicity in the actual world. No one has a simple experience with python dependency management after a year. SSR is really simple, if your clients have a good internet connection. It is a whole other story when you are doing other stuff. * "I like minimalism. I only wear black clothing" well good luck in a country where winters are 30°c. Your situation may have a specifically simple solution. But 1. That solution is not universal 2 You won't know it before hand. 3. If you start with a wrong solution the graceful change to the right solution introduces 90% of the complexity.

[@Muskar2]

I'm convinced Conway's Law is a large part of why we have all these things, particularly microservices. But also, once people learn the doctrine of how to do things, it can take a lot to rewind to fundamental truths. E.g. I think most applications could even work well without any database at all, and would be radically simpler for it.

[@tinyrobot7443]

I'm building a small project right now with a prediction of about 20 TOTAL ACCOUTS and maybe 1 or 2 accesses per minute PEAK. I just use django. I was asked why I didn't use something more performant. That is the world we live in.

[@dankprole7884]

I feel your pain

[@GimmeMoreMilk]

I agree to some extent, but Postgres only scales so far for full-text search, and there are simpler options than Elastic that can be a good choice. They do mention it, but don't be scared of using Redis if you need it, it's pretty simple.

[@mats66]

I've been taught and my development team always employ this method: Start simple and optimize only when needed.

[@Nezteb]

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. 😄

[@zeppelinmexicano]

The Great Tom laughs at simplicity. In fact, he wants a system that explodes when you put comments in the code.

[@bzboii]

radical simp city

[@vaxrvaxr]

I remember Sim City. It was great on the SNES.

[@jamesarthurkimbell]

"Can we just be real for a second?" I thought we were still being real from the last time you said that

[@mrsearaphim4077]

One of the reasons why small companies try to support scaling early is because they want to be ready for a potential instant boom of users. For example, your competitor shot themselves in the foot and now their users are looking for an alternative but your services aren't able to keep up with the demand. You've now lost a massive opportunity for growth. I have seen it happen. But yes, it is still a massive risk to bet everything on that. There's also the venture capital side of things that explains why we see this so often.

[@Pekz00r]

Yes, this is a great take. I agree pretty much 100 %, except that crazy take with scrum. A startup should be lean and use something like Kanban with minimal processes until get grow into a pretty big tech team. You might want to start with a quick and dirty prototype, but the first real version of the service should be a monolith in probably 98 % of the cases. The monolith should be divided into modules in some way, for example DDD, with minimal coupling between that modules. That makes the work of splitting out parts of the application a lot easier if that is necessary, but with a good structure that point comes pretty late and you will then have resources to do that properly.

[@sealsharp]

I thought about complexity a lot related to gamedesign. Complexity imo is "costs" to depth. Increasing depth also increases complexity, but increasing complexity does not increase depth. So the optimal solution would be to get the most depth at the least complexity. Obviously, a few of people got very mad at me fo that. lol.

[@CodeCowboy64]

"I spend all my time building the problem." - ThePrimeagen (and every other dev)

[@Twoface227]

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

[@stepankotyk8823]

i remember we migrated from AngularJS to NG6 large enterprise app, and it went for 2.5 sec full load to 12 :D

[@schism15]

Don't reinvent the wheel vs reinventing the wheel (i.e. getting deep understanding from building). Man, I feel that conflict very strongly. In a way it's like as an engineer you are at fundamental odds with the business. The business wants features, faster. If they can get that by hiring engineers who know just enough and then have them always working with every new framework/tool/AI product/abstraction that promises faster results, that's what they'll go for. But it leaves the engineer less time to dig deep and get greater understanding. This can have a small negative impact on the business (that may even get cancelled out by faster iteration), but potentially large negative impact on the engineer over the span of their career.

[@UnderTrack_]

what brought me into programming isn't the new tech (I'm like 10 years behind on most dev world news it's horrendous), it's neither problem solving alltho that's enjoyable. It's mainly that I'm in a mindset of always doing things by myself when I don't have a sufficiently satisfying experience with said thing; it can require manual labor, reading or researching in books or just bruteforcing to get it done, at worse I just learnt about something and it can be usefull knowledge which is cool, at best I have a new thing, maybe it's better, maybe it's worse than the one I was trying to improve on but in either case, I gained experience to do better the next time.

[@MortenBendiksen]

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.

[@fullmastrinio]

"If you have more microservices than users press 1" man you did not have to slap that hard