Don't get me wrong, it's not difficult... it's just way more fucking complex than it should be.
I'm coding some framework atm and decided to do it the right way... you know picking a language (and version...), choosing the right paradigm, doing TDD, creating CI/CD pipelines that trigger automatically when you raise a PR but can also be ran locally (oh and of course setting up github/azdo/bitbucket/whatever), choosing a license and prolly a whole lot more that I don't even realise. The only thing I didn't bother with (yet...) is code coverage. And all that before writing a single line of code.
And then totally unrelated I wrote the following script:
$ vim ~/bin/aur
#!/bin/bash
git pull
makepkg -i
And kept thinking how elegant and readable this is... and how I could royally fuck it up if I would do the right way.
Disclaimer
Just to be clear, this post has no point whatsoever. It merely raises a whole bunch of questions and maybe some solutions... or rather asks the reader (yeah that's you) to come up with solutions and hopefully share them.
Why do we do all this?
Honestly software engineering (aka coding) is an complete intertwined shit-show, which is so easy to dive into (Hello, World!) that everybody think they can do it... and consequently think they know better. So much so that people that never wrote a line of code are telling devs how to do their job. Which is probably the first hint at why we setup such an elaborate maze of tools, practices and processes...
Accountability
If something breaks, it's the dev's fault... not the PO for writing up a half-arsed feature or QA for not testing that 1 in a million scenario that he/she didn't have time for... or the CEO that doesn't want to spend more on their bread and butter.
Yeah that's right, software is your USP these days! The only way your gonna have an edge over your competition (in most businesses anyway) is to have the right tools and if those tools don't exist, you'll need to create them. You can have the best product/service in the world but if you don't have the software to back it up, your competitors will overtake you in an instance. That said, wouldn't it be nice if we could do it cheaper? Or at least smarter, cuz otherwise so could the competition...
Anyway, we're all accountable for the software we create, but we also need to be able to be accountable for it. So how can we be accountable for something ever-evolving and so complex that we can't even begin to understand what can possibly go wrong?
Over the years we came up with a whole bunch of things (ASD, CI/CD, DDD, FP, XP and the list goes on and on) in an attempt to solve the problems we faced. But what actually are those problems? And why do these solutions also create an equal amount of new problems? And why is there so much crap that I need to understand to write 1 line of code?
Fluidity
Probably the biggest problem that people generally tend to miss is the fluidity of software. When you build a (physical) house, it's pretty much fixed once it's done. You wouldn't decide the next day to add a swimming pool to the top-floor... and if you did, there would be at least 20 people telling you that, although awesome... it's a stupid fucking idea. In software however, the consequence of putting in a swimming pool isn't that it's gonna collapse and kill everyone in the building. It will weaken the foundation a bit but hey what's another bit of technical debt?
A fundamental part of this however is the ever-evolving nature of software. It's never finished and it never goes in the bin. Once a line of code is committed, it will likely stay there for the coming 10 years. And the problem with that is you didn't consider how that big-ass pool is gonna affect it, as no-one told you about the pool... or even considered it. As a matter of fact that 1 line of code may inspire someone to suggest that, if we can do this... we can also build a pool, right? What we create is often the inspiration for the next thing, potentially taking it in a completely new direction. But is the foundation strong enough for this?
And there is also the matter of all the legacy crap we keep carrying around. How do we ensure that that keeps working as expected? Cuz even though we wanna bolt new shiny things on top of it we can't loose those old (formerly shiny) things. Back in the day coding was a lot more like building a house, we'd do it once and a year later we'd build an improved version of it, having ample time to validate the old crap... not anymore.
Resilience
Although related to the fluidity in an architectural sense (how well does it cater for change?), resilience in software also relates to how well it runs. We expect software to always work but develop it in the narrowest possible conditions... "it works on my machine". And that's partly why a dev will always say it should work. It's so complex that dropping the exact same code on another machine typically will fail spectacularly!
So how is it that we created something so complex that we can't even predict whether it will work, let alone how well. Which is pretty impressive as everything we do is at the end of the day a very binary choice. But why than can't we deliver on the expectation that it always works, regardless of the conditions?
We need ensure all prerequisites are exactly met and otherwise it simply won't work. Tools like Docker will help us with that but there's still an endless amount of variables that we don't control... or even consider. Chaos engineering is one approach of making things more resilient but that's a requires a pretty hefty investment. Also it assume your software works, but what does that really mean? That it runs on your machine / prod cluster given the exact right circumstances? What if I want to run it on a new test cluster? How much shit would I need to setup before I even can start throwing a simian army at it?
Scale
If you write a quick little bash script like the AUR building example in the intro you can afford to ditch all the best practices. Or at least it's relatively safe to assume it's not gonna get extended or used anywhere else or by anyone else. But the bigger the stakes the more important such factors start to become. Lets say you want to provide a AUR building SAAS platform, that piece of code at the top is probably gonna be in there somewhere... but you might also wanna consider a microservices architecture... among 20000 other things.
It so depends on what you're end goal is on how "well" your code should be written. And the terrible truth is that half of the time we're figuring out the end goal along the way. So how can we make a proper judgement of how solid our code needs to be? Especially with a PO breathing down your neck who wants to get the feature out asap... and then bitches 2 weeks later that the next feature is taking too long cuz you need to clean up the mess of the first feature. So how can we write good enough code that don't have to rewrite/bin 2 weeks later? Or should we be writing throw-away code? And if so is there an architecture that actually facilitates this? And would the business even accept that? It is at the end of the day our IP, right?
Security
Another important (and royally underestimated) reason why such an overcomplicated mess of crap is needed, is security. We put locks on our doors to prevent unauthenticated and/or unauthorised people from coming in and additionally we also create secure briefcases to carry important information from A to B... and figure out how to deal with lock pickers and continuously monitor if our building is still up-to-date with (literally) today's standards. Or at least we should.
So how do you write secure code? How do you ensure your dependencies are secure (remember log4j?)? The long and short of it is: you can't... at best you can write software that takes more effort to break than the value gained if someone would break in. In other words the bigger the pot of gold your software is protecting the better security you need.
But half of the time people don't even know that the code they're writing is full of holes. And you can't really blame them as it's such a vast and complicated topic that fully understanding, in addition to all the other crap you need to know, is nearly impossible. So how do we create secure code then? Without having know every last little best practice or implement code scanners (and understanding and dealing with the results)... Or should we just deal with it in relation to the scale? i.e. initially the pot of gold is pretty small so who cares? But it would be so nice if it could be secure by default... like resilient by default...
Conclusion
So lets wrap this up for now. Normally you'd put some nice lessons learned here but there are none... other than coding being overly complex... but we kinda knew that when we started.
Here are a bunch of questions that I think we should consider... and that I might consider in future writings:
- How can we be fully accountable for what we build?
- In other words how do we create control over what we build?
- How do we deal with the ever-evolving nature of software?
- How do we stay in control over what we've built and what is still to come?
- Do we just start building and scale when needed?
- Or can we easily build for scale?
- How can we build secure enough software?
- Or can we make it 100% secure by default?
- Should we be proud of the vast amount of crap we created in the last 70+ years?
- And how do we condense all this in 1 person's mind and expect them to create wonders?
Lastly, what if we had a greenfield? How would we deal with these problems? Could we do something radically different?
Top comments (40)
My "solution": write less code 🤣 No, seriously, I attempt to code in a minimalistic way, to reduce the features to the "Must haves" and using libs without too much magic. But sometimes, it's tough.
The other thing I think people overlook is that adding features is not linear in complexity. They typically interact with the rest of the system. As such, the cost of each added feature increases exponentially. Even a small feature that you add now is likely to cost you in the future. This typically culminates at some point in a system so complex that nobody really understands it and where the slightest change becomes challenging.
I see that at work right now: "let's make an authentication module. It should support username/password, OpenId, OAuth2, SAML, Kerberos, NTLM, registration/recovery features, custom branding ...and multiple of those at once of course, multilingual, distributed, iframe compatibility with popups, lots of client-side legacy stuff ...and yeah, make it simple to configure ...based on some outdated complex inhouse frameworks and a plugin mechanism" ...I'm not kidding 🤒 ...tomorrow again I have a meeting where it feels like a conflict of interest between "the reasonable me" wanting to keep feature creep in check and others being like "hey man, it's just a login screen, just add a few more features, why is taking so long anyway?". No wonder stuff becomes "so ridiculously overcomplicated". It starts with the absurd requirements.
Wow it almost sounds like the authentication merits its own PO & Dev team... maybe instead of asking "can we do this?" we should be asking "should we do this?" Writing less code is indeed the key... but maybe we should achieve that with less features / bells and whistles? And/Or throwing old shit away... do we really need everything and the kitchen sink?
You're also spot on with exponential growth of complexity! And while architecture can help keeping this at bay a little, this may be more a product problem than a technical problem...
Oh man, this...so true and so much memories while I read this
It seems some lessons learned in the past have been simply forgotten. After several companies crashed in the 80´th being not able to handle the complexity of their products, software development was all about reducing complexity. One of the targets was to build platforms, where distributed teams where able to work together, even if they used different programming languages.
When people started to write code for their websites, some lines of code often have been enough. Javascript started as a scripting language and was initially not meant to be a full featured programming environment. I suppose, the same is true for PHP. So, tools we are using today are not comparable to the tools we had before. Things are still a bit hacky and full of compromise to be backwards compatible.
If you start to use something completely new and different, you will see, that nobody cares for it. They all are so used to do things the way they are used to, that you will hardly find any good response, even if you build something that could radically change the world. There are so many people that still think, HTML is a programming language. No way to change their minds.
It's indeed interesting how something PHP evolved over time... I was baffled when they dropped goto in there (and given the XKCD on the documentation page I think so was everyone else...). Begs the question: why do we need all that? What's next? OOP in bash?
I do think new environments have the potential to be adopted (e.g. Go, Rust) but they're still quite close to what we're used to. I vividly remember a UX discussion on hamburger menu where the UX designer said: we can't move away from it too far or people won't get it, it'll need to evolve over time... I guess the same holds true for coding.
Still would like to know what the ideal environment is tho... there are a whole bunch of good things to be found in any language/environment that we should definitely keep around but how do we distil all that to its essence and make something new out of that?
Maybe things would simply take more time to grow...
yeah we can't sit still can we? as an engineer we can always see ways to improve it further... and as a PO we always want another feature... the fluidity is very much self-imposed 😃
Coding is not that complicated, software engineering is! Code is nothing more than an implementation detail, once you reach a place of maturity in your software engineering career you should aim to become resistant to introducing code into a system and focus more on how you can delete code and more process-related tasks and documentation.
Cleaning up and having a healthy reluctance for new stuff yeah, but "resistance" to me implies not making any changes unless absolutely necessary... how do you get the product/service to move forward?
It is just an interpretation of the word but what you said above implies what I meant.
So are you saying lets be less ambitious with the software we created and instead make it work perfectly? I.e.less is more... so we need to educate Product?
No that is not what I am saying at all! I am perceiving that this comment chain might end up going into a logic trap or they call it "leading the witness" in the courtroom.
not my intention at all, just trying to figure how to apply "resistant to introducing code" in day to day? How do you do it?
Have you had a look at defensive programming as a methodology? Check that out then you might get a better understanding of where I am coming from :)
Oh yeah absolutely, another thing I forgot to add to the ever-growing list of how to create good software :)
Defensive programming is a core methodology for me.
Exactly. I've covered this issue in depth and provided numerous methods for overcoming the problem here: craft-code.dev/methods
The fundamental reason for this drive to overcomplicate things is – and no one is going to like hearing this, but it's true – the immaturity of developers. Most humans, not just developers, are immature. We have a youth-obsessed culture and a bad global pandemic of Peter Pan syndrome.
Almost all the bad practices in tech – and the overbearing processes introduced to counteract them – are the result of immaturity throughout the organization.
Adults do the right thing. Every time. That is the definition of an adult. We modern humans "grow up", but somehow we no longer become adults. This is as obvious in the global situation – constant war, destruction of the biosphere, etc. – as it is in the microcosm that is web development.
On the global level, our failure to become adults will lead, if left uncorrected, to our extinction. On the local, tech level it leads to an enormous waste of resources overcomplicating things, building unnecessary junk, re-creating the wheel over and over again, competing where we should be cooperating, and trying to clean up the mess that all the above leaves.
Our efficiency is in the single digit percents. And that has implications that are indeed global in scope.
You know it. I know it. What are we going to do about it?
That's awesome (craft-code.de that is :)), but how do we ensure that all these great lessons are actually absorbed by the people that need them most? I'm wondering whether just giving someone and IDE and tell them to "write good code" is the way to go these days... especially since there are so many contradicting opinions on what "good code" is :)
Frankly, I think it is probably hopeless. All of capitalist society is focused on infantilizing humanity — the better to control us and to sell us junk that we don't need. That's an enormous force with which to be reckoned.
But if we are to move forward instead of backward, we have to focus not on minor issues such as writing good code or building more, faster (more what? why?), but on maturing individually and as a society. That means holding ourselves accountable. The first move in getting others to do something right is to do it right yourself.
Too many people want to be the last person to do the right thing — "I'll do it when everyone else does" — instead of the first. craft-code.dev/ is my own attempt to "eat my own dog food" as they say (we need a better cliché). And I have other efforts that deal with issues beyond coding as well.
After all, I am accountable for my own part and no one else's. Too many of us focus on "them" being the problem. Physician, heal thyself, I say.
When the problem is holistic the solution must also be holistic. Partial solutions are just a game of whack-a-mole. We are never going to solve any of this by nibbling away at the edges. We must go straight to the root. And the root is our lack of maturity.
But what part of immaturity is the problem? For a dev an open mind is actually a good thing (e.g. how can I break this?) as it leads to better software.
I've always tried to balance processes with the maturity of the people that execute them. Some require a traintrack and can only go left or right if the controller allows them to, others you can give motorbike an tell them to just go. Traditionally devs were given motorbikes and I'd like it to be that going forward. But can devs still deal with that responsibility? Or should we consider that there are many kinds of devs? Not just in maturity but also in mindset... a dev in a startup is a different kind of creature than in a big enterprise.
But if we assume we want to give them all a motorbike, i.e. reduce the amount of processes, how do we ensure they're mature enough? Is this an educational problem? Is it even a software engineering problem or is the constant pressure of delivering whatever the next supposedly important thing is? Or... ?
Everyone will attempt to fix it with a band-aid. The real problem is a sick society. Changing that is such an enormous task that we'll bikeshed forever first. It's a bit like someone with a bad drug habit. They have to bottom out before they get better. There are still far too many people around who think that we're going to "tech" our way out of this mess. But tech is only making it worse.
Actually, tech is the most potent drug of all.
Sadly, things are going to get a lot worse before they get better, and most people aren't even paying attention yet. The house is on fire, the kids are trapped in the attic, and we're arguing about what color to paint the garage.
I guess in order to change this for the better we need a common goal that everybody can identify with and work towards that. Deep down most people know we're heading in the wrong direction but it's easier not to change course as there is no direct benefit. And this consequently means that something will need to break so drastically that everybody is affected and can't keep doing what they were doing before.
Sorry for the lengthy reply, but this is an extremely important issue, of which simplified coding is a very insignificant example.
A common goal is easy. How about our survival as a species, which necessarily permits our survival as individuals? You might think that the survival instinct comes into play. But you'd be wrong.
The success or failure of our species depends on what a large number of humans choose to do. No individual can make an observable dent. No one. So there is a significant risk involved in bucking the group.
What if you do everything right, and this comes at a cost to you – perhaps even a large cost – but no one else does the right thing so you suffer twice? Logic would indicate that we should do nothing like everyone else. Of course, most of us are busy making things much, much worse, so doing nothing might be an improvement.
But the problem with this is that everyone else is in the same bind. So when we choose to do nothing, we are effectively becoming that "everyone else" that we used to justify doing nothing ourselves. It's a vicious circle.
This is a well-known dilemma, although few people seem to think about it much and what it portends for humanity. It is called the Prisoner's Dilemma and it has to do with acting selfishly vs. selflessly.
When everyone acts selfishly, everyone suffers: i.e., we go extinct. But when some act selfishly and others selflessly, those who act selflessly suffer more, while those who act selfishly appear to profit, or at least suffer less. I say "appear" because we still go extinct. The selfish ones simply "die with the most toys".
That's actually a great little quip – "he who dies with the most toys, wins" – because it should make immediately obvious to anyone but an utter infant that it is infantility we are discussing here. After all, who plays with toys?
The only way out of the Prisoner's Dilemma is for everyone, or nearly everyone, to act selflessly. And sadly the only way to get that outcome is to punish those who act selfishly. As most of us are quite selfish, why would we want to punish selfishness?
So this is the problem, and it is evident at every level of our society: from the actions of states all the way down to the way individuals interact on a software development team or the way enterprises are run.
Selfishness is the nature of the infant. There is nothing wrong with this. Infants must be selfish to survive. It is only when they have acquired the skills necessary for independent action that they can afford to become selfless. The stronger and more independent the individual, the more selfless that individual can be.
Selflessness is the nature of the adult. Adults understand the Prisoner's Dilemma, but instead of shifting the responsibility onto the other players, they take it upon themselves. This is a distinguishing characteristic of adulthood: adults embrace and assume accountability for their actions. In short, an adult always does the right thing. If you do wrong things knowingly, then you are not an adult by definition.
You can propose other definitions for an adult, redefining adults as infants, but you're simply playing semantic games and fooling yourself. It doesn't matter what terms we use. Call it enlightened vs. unenlightened if you prefer. What is important is does-the-right-thing-invariably/does-not.
By this definition virtually everyone on Earth is infantile. We do wrong things daily and we know it. We act on impulse. We indulge our worst whims. We are infants. I like that term best because "grown ups" – those who got older but no wiser – can't stand being called an infant. It hurts. It really gets our attention.
As infants, we continually make the wrong choice in the Prisoner's Dilemma.
The game cannot be changed, but that is what everyone wants and is waiting for. That's everyone who says the problem is the "system". Sorry. It isn't. We are the creators of the system and we can create a different one. We decide the system. The system does not decide us.
We cannot invent a system in which everyone doing "wrong" things works out well for us as a species. Or even as individuals – hoarding and wasting obscene amounts of desperately-needed resources is not "winning", but putting lipstick on the pig. You lost everything, and your hoarded wealth is just the consolation prize. Oh, someone once said something smart about that ... For what shall it profit a man, if he shall gain the whole world, and lose his own soul?
This brings up an important point. We all already know the answer to all these silly questions. The problem isn't that we don't know what do do; it is that we desperately don't want to do it.
So the solution to all of these issues, from war, climate change, pollution, violence, exploitation, etc. all the way down to parenting, working on a team, running a corporation, or, yes, writing simpler code is simple: grow up. Work assiduously to become an adult human being as soon as possible.
We must be the solution. Each of us must make the right choices. It must start with me, not finish with me.
Immediately, most people will respond with "that's never going to happen". OK, you're probably right. So then we're screwed. So just STFU and wait for the end. There is nothing else we can do. I prefer to think that we can do something and that this is just an excuse made by whiny infants and cowards.
The other very popular answer is to attack the messenger: So what are you doing? Here we see the classic, infantile "you first" response. People who say this want to be the last to grow up. But what other people do is irrelevant. I am either and adult or I am not. If I'm not, then I'm either striving to become one or stubbornly remaining an infant. What you do has nothing to do with me.
I don't see much hope for humanity – or simplifying coding – not that the latter is of any importance in the larger scheme of things. But I, personally, am doing as much as I can to be an adult. And that applies from how I write my code all the way up to how I live my life. It's actually not that difficult: just do the right thing. Every time.
And all of us know what the right thing is.
But I do think simplifying coding (and open sourcing things for that matter) is actually helping people to grow up. Although you need to have an intrinsic drive to do the right thing, it does help if your environment is motivating as well. Making it easier possible to use external "help" is something that in my opinion also contributes to the bigger picture. If we share, educate and converse with the intention to do good (or at least better) we help each other. It's an enormous amount of small things that will ultimately shift the balance.
I hope you're right and that it's not just helping us to build more manipulative toys (antisocial media) or spyware. But I think there are parallel processes here. Context is, as you point out, very important. We're social, tribal animals and your parents were right: your friends define you.
So I'm all for simplification (I have a whole website dedicated to it), but in pursuit of good objectives. Too often we devs focus on the task at hand and never stop to ask, Why? Who does this really benefit? Who does it hurt?
But then the pushback from devs like the folks at Google who resist building more spyware for the NSA is a good sign or unaccountable "AI". (Google's new motto: Do evil. Lots of it. Lie about it.) So devs (and other engineers) are slowly waking up to their responsibility to, frankly, all life on Earth. Sadly, we don't talk about this enough on sites such as Dev.to, and many devs strongly resist discussing it anywhere at all – tuning out or complaining that it's "OT" when it comes up.
In my mind, the survival of life on Earth is never "off topic", and should be the primary thing we talk about. What else is there, really? Otherwise, as I said, it's as if the house is burning, the kids are trapped in the attic, and we're arguing about what color to paint the garage.
Nice chat! I appreciate that you cared enough to continue and weren't scared away by big topics. If only we were legion.
Cheers!
For me the purpose of this post was to ask why a couple times... why do we do all this? what is the actual purpose? What is the actual problem and why do we think these solutions solve that? Stepping back and asking why is probably one of the most powerful and underutilised tools we have as a society. And it's not even about doubting everything... just for the sake of really understanding why we do things.
Looking at the bigger picture and seeing how this community can help improve it prolly merits its own series on dev.to. I would imagine there are more people interested in ensuring the survival of our species :)
Good chat indeed!
In case the point of view of a psychologist is worth it, I believe that the problem of complicating programming is due to egos and capitalism.
That is, creating a need to base a business around it.
For example, data science, to analyze different problems with different methods, is complicated. Given its nature, it is complicated. And yet it tends to simplify as much as possible. The psychological framework of people who seek information from data and knowledge is different.
But coding... I'm thinking about JavaScript, the paradigmatic overcomplicated language since this conception, has become a businesses complicated for nothing stupidly language.
Each new revision ESXXX implies new books, courses, videos and so on. It also psychologically brings exclusivity closer to those who want to feel that they are special. Being able to say "I know the new crappy implementation to create loops with the new xxx standard." Ego. The more complicated, even if it is stupidly complicated, the better I feel because I need to know that I am not equal to anyone, but that I am superior in something. What could be made simpler? No, that's not cool.
I think that's the current mental framework in web design, specially the backend people and their glorious fashionable frameworks. That's why they hate old and simple things.
Basically, it is the social reality in many areas today. We no longer want to be equal, we do not seek equality, what many people need is to feel superior, even if it is symbolic and enjoy privileges for free effortlessly because I'm special and feel so special in any thing.
People, and dev in particular always want things to be "better". I mean the whole purpose of this post is to see if we can improve things. But it's indeed so easy to fall into the trap of changing things for the sake of changing things... or worse, to show off you're better. I actually think we seek individuality... and in some cases people think superiority is the same thing.
Another thing we shouldn't underestimate tho is the expectation of change... if a github repo didn't have any updates in a couple months it's considered dead... How about it's good as it is and we don't need any new crap? While often there is a (rightful) demand for new things, there's also an implied motivation to come up with new features because otherwise we can fire the product & engineering team. So self-preservation is also an important factor.
The culture of always making updates and adding new features inevitably screws up the things that are already designed and working properly which don't need to be changed.
Engineers sometimes overcomplicate things either deliberately (they take enjoyment in the convoluted) or inadvertently (they don't take a step back to look at the big picture using common sense)
The culture of pressure to get things done quickly means things are often fixed in a haphazard and convoluted manner.
Those are the reasons why coding is overly complex.
No, its false, what is complicated is to understand what problems you should resolve, and resolving it. What is overcomplicated is when you try to overengineer because you dont clearly define the problems you are trying to resolve.
Just a clear example : you want an app who planificate booking reservations, do you need to be an expert in postgresql or mysql ? no, you build a first version of this app, without being an expert, and maybe after, you will read more documentation about how to structure the data, improving performance. Why you should be an expert in everything ? just why?
My point is that coding is the easy bit, assuming you indeed understand what the problem and you don't overengineer it. But in order to apply all the (supposed) best practices the amount of stuff you end up doing before writing a single line of code is ridiculous.
That said it does very much depends on the scale you're building for... a simple website doesn't need a code scanner or even TDD, but a bigger piece of software that gets released weekly requires a whole lot more. In the former case just indeed spin a mysql container and get chatgippiti to generate you a couple schema's. Now imagine that it grows to serve 100K+ people, you would need to retroactively introduce automated testing to be able to keep releasing regularly... would have been nice if you started with that right at the beginning. Or lets enable a code scanner on a 2 year old code base... you're not gonna be happy about what it's going to tell you :)
So no, you don't need to be an expert in postgresql to get started. But being able to consider all the best practices and what to apply and continually do that, isn't an easy feat.
yes the "supposed" best practices.
The point is here
Great post 👏
I'm waiting for the time I can blame an AI for bad code, why do you want to be accountable 😄
I love the large swimming pool on the roof concept and how that spirals out of control in multiple ways 😂 Very curious to see people's perspectives on the aforementioned questions.
I love taking real-life engineering problems as a reference...