hey there, how long will it take for my system with i7 chip. no gpu, 15 gb ram??? it is taking quite a while for me, thanks for the video it was really helpful!!!
Glad you liked it! I am afraid that without a GPU it takes a lot of time. I got an RTX 4070 and it's not taking longer than 5 minutes to index a page, but I tried using the onboard GPU and it took forever (I had to stop the process manually).
As someone working extensively with AI in programming, ChatGPT is much better then Gemini. If Gemini does something well than ChatGPT as well. But there is a lot of situations that ChatGPT is doing great job and Gemini just fails.
I agree with everything except for the conclusion. Good software engineers will be more valued as time passes, because everyone will have the same quality problems+ lack of deep understanding. To fix even "trivial" issues, they will need real developers. So, to be honest, I am rather happy with the current context 😊
With my 7+ years of experience I can agree with everything. Sometimes I just don't understand how some big companies like Facebook can create such shitty UX across all of their apps
I disagree fundamentally. What you have stated are mere symptoms. Observe that every new programming language is often trying to fix some problem from a previous programming language. For the most part, we might say that in some sense, every new programming language is trying to fix C, but not software engineering. I would like to state that I am also not speaking as a matter of mere experience, but from the perspective of correct theoretical knowledge. The issue is fundamentally a philosophical, primarily ontological issue: ontology is an essential part of design whether you realize it or not because in order to solve any problem, you have to know what it is. Answering the question of "What is a class" is already an ontological question, as is, "What is a graph?", "What is a car?", "What is an X?" whether we're talking about abstract data structures, or concrete existences. A wrong answer to what these whatnesses are leads to bugs which are a failure of implementation to conform to design in the best case, and an error in the design itself in the worst case. Designing is nothing more than comprehending and specifying essences or whatnesses: and our jobs as software engineers, therefore, is nothing but comprehending and specifying what things are, and then making those specifications actual by way of hardware. Now remove correct philosophy from society and you get precisely the mess we are dealing with, for instance, in the software industry. It's the blind leading the blind, each thinking he has the true solution, when in reality, he knows no better than the next guy, because sound and true philosophy has been forgotten because some guys a few centuries ago decided not to listen to reason, and it was more convenient to just cave in to such errors than face the reality. Thomism is the best philosophy out there. Consider reading courses such as "Ontology, a class manual in fundamental metaphysics" by Rev. Msgr. Paul J. Glenn, for starters. He has several other philosophy courses that should prove useful, and I'm sure are available on The Internet Archive just as this course is. Read it. Start making the connections between programming language elements and what they are such as variables, structs, and classes. You'll thank me later. Completely changed my whole perspective on our field after I got into philosophy.
@@bitheap-tech There are two kinds of people in the world: those who originate thoughts, and those who merely believe the originators perhaps through still other mere believers. The latter is most people today. The former shrinks day by day.
@@bitheap-tech It's nevertheless proven from first principles: Knowledge is known or believed by intellect or by faith (such as the word of others) Many today make claims without any premises, or at least satisfactory premises Therefore many today know or believe what they do because of the knowledge or faith of others Finally, those who know or believe not of their own intellect necessarily get their knowledge and beliefs from others Knowledge and belief cannot originate from what lacks the ability to know and believe of itself Therefore in a chain of those who know or believe by others, there are one or more originators who know and believe first that have communicated their knowledge and beliefs Quite simple really. The syllogism isn't taught in schools today. Now why might that be🤔 Well, I'll refrain from giving an answer since I don't know for sure, but I will say that it is easy to manipulate a crowd when you tell them they are nothing but advanced monkeys and emphasize sense knowledge while dismissing theoretical knowledge. Theory and practice is merely the difference between what a thing is, and how it is implemented: the ancient principle of hylomorphism first practically studied and comprehended by Aristotle. The failure to recognize this is why it is an incredible deception to dismiss all theory as bunk and only trust what one can sense. This is none other than empiricism (idealism its opposite), and it is an incredibly limiting and erroneous doctrine.
The steps you’re taking in your arguments are way too big. I don’t necessarily disagree with all of the things you’re saying, but it’s cobbled together very messily.
@@bitheap-tech How about not making polemic and bland statements, like "people that discuss TDD are worthless". That is a useless, and obviously false statement. How about not pretending, abstraction is universally counterproductive? That is obvious nonsense. You need abstractions like memory management in some form. Do you know how incredibly labor, money and time intensive it is, to build large applications on a low abstraction level and needing to do manual memory management? This is a tradeoff between development feasibility and performance. Performance is not the be-all and end-all. Not reflecting all these multi faceted concerns makes you look very immature, and your argument riddled with omissions, falsehoods and other fallacies. Also, there are very performant languages with high level of abstraction of hardware, such as Haskell. The problem there is not the abstraction level of the language, but the intellectual laziness of average developers to learn to work with this abstraction and type of language. Haskell is a perfect example of a great tradeoff between compiler checked code that reaches into semantics in some areas and very high performance, not far behind C++ etc. And all of this by the power of abstraction.
@@ElizaberthUndEugen was replying to you. Weird that your comment seems to be removed (I for sure haven't removed it). Do you see how ironic this is? A software bug in a page that hosts a video about how buggy software is.
thanks for this. i'd love to see a follow up video discussing where I.T. was right around Y2K and how, at least at a few companies or on some Projects there actually WAS effective development. For example, Red Cross applied CMMi level 5 and had very few bugs, was performant, and secure. Boeing used SDLC, same with NASA, financial firms, countless others. What happened? when did Use Cases get downgraded to the glorified post it notes people call "user stories"? What would posses people to abandon teams such as Requirements Management and Configuration Management and adopt CI/CD? Oh sure, just go from code check-in straight to prod; what could go wrong there? SMH. When did people stop doing formal design reviews (PDR/CDR) and just let devs "sprint" and check in their crap whenever they deem it done? how the hell is a tester supposed to prepare for testing something if all they have is one of those jira post-it notes that says "gosh, when i click this button i'd sure like to see my billing info" really? is that what we call a Requirement now? Is that what we're settling for instead of use cases? remember those? from the super famous UML purple book? In fact, what happened to Process in general? shops nowadays have almost zero Process, maybe just de-facto standards like using github, IDE's, docker images. and yes, these are fantastic improvements, but should never be replacements for formal software Control. the log4j disaster would never, ever have happened back when CM was a thing -- they would never in a million years have even allowed some outside dependency into a build. It's just insanity. Look at us now, half our crap software is built on open source. this is not software engineering, it's the realization of mark zuckerberg's n00b idea: go fast and BREAK THINGS
As a software-engineer myself, I put full responsibility on: A) Sales, because they constantly sell things that are impossible to create in any realistic manner B) Software architects, because they're just to incompetent to code themselves. C) Management, because they believe everything A and B tells them... I just spend this workday, writing a library whereof I know it's going to cause a plethora of problems. Not because my code is bad, but because the whole architecture of the code base is the equivalent of a cesspool! But yeah, management made sure that the previous guy who complained to much isn't with us anymore! So everyone just shuts up and writes code the way the're told to...
I honestly wish many of these large corporations would actually take time to create and then launch apps/websites that are completely functional and not overly bloated with ads and random BS because someone needs to justify a job that really shouldn't need justification. You coder dudes are there to build, bug fix, and maintain your crap not build junk to fulfill some stupid persons idea of productiveness.
I have been programming since 1984. You nailed some solid points. It all makes for unmanageable software with an uneven user experience - not to mention turning a creative role into metric-driven drudgery.
The software industry is pathetic. But it's not really so much the "fault" of current programmers. The seeds of this situation were laid decades ago, and we've just continued to dig the hole deeper ever since. The original problem was that we let legacy software steer the development of new microprocessors. What we SHOULD have done is let the hardware guys figure out how to give us the best, most performant, most secure hardware possible, and then we do what we have to do to use it, even if that means re-writing some software. We should have kept the architectures SIMPLE, easy to understand, and then we'd have had had a SHOT at keeping them SECURE. The second problem is over-relaince on libraries. Modern programmers don't really want to write software - they want to stitch together libraries, without understanding how those libraries actually work. There's just no way to keep the stuff secure when the programming team doesn't really understand the big picture. Ten million code monkeys is NOT better than ten thousand truly exceptional programmers who actually DO understand what they're doing. I agree with EVERYTHING you've said here.
I think the main problem was to let idiots runnning the ship. I mean, in any industry you don't see a person running the show without knowing anything about. But here I am developing network scanners for managers who could not say the difference between DHCP and a cup of coffee.
@@rocknowradio I totally agree - I've always believed tech development projects should be run by someone who actually knows the tech. That's the one person you most need to understand the "big picture" and how everything fits together. And his job is to make sure that all the pieces developed by the younger, less experienced people on the team are actually going to "fit together" when the time comes. This "pure manager" thing, where you just have a guy who knows some agile lingo and is good at slapping sticky notes on the wall running your show, is a fail before you even start. And the other part of that leader's job is to also be teaching those younger guys WHY the decisions are made the way they are, so they can grow up to be leaders too. He or she should be watching and taking note of who shows promise, etc.
Bullshit. I didn't see a blue screen in years. When using windows ME, I saw one every week. How was security 15 years ago? You could elevate by replacing screensaver.exe. PHP was basically a collection of vulnerabilities. Basically the only thing that stay is video games. Reducing this whole video to actual just complain about the video game market.
I immediately subscribed to your channel. I agree with pretty much every point, especially lack of deep and meaningful work - it's difficult to focus nowadays and work in big firms has a lot pointless calls and administrative tasks. As for scrum - it's pure evil. I don't do programming, but I use code and so far our the worst managed project is the one that uses agile/scrum.
I'l throw my 2c in as a hardware and software engineer. Programming 40 years ago just seemed more fun, there was a problem to solve, a C compiler to compile the code and an OS to host that, the OS and C compiler were about 1000 times smaller and the processor architecture was also perhaps 1000 times simpler, compare a PDP11 and unix circa 1980 to what we have today. My personal rule is don't program in a language for which you can not understand how to build the compiler you need. That today is impossible since say Visual Studio is at least 10-50GB install while ThinkC and other snappy compilers 35years ago could fit on a floppy disk or two and performed at lightning speed when incremental compilers were first used. Today VS always takes a few sec. The debugging tools are hugely worse than decades ago. Perhaps we should be focusing on tools that are as elegant as smalltalk, lisp once were but are now largely forgotten. So now we have to learn Rust. As a hardware engineer, I always felt that hardware code was easier to debug than software code, but then hardware got massively complex too. Back in the day of N Wirth, all the new languages were simple enough that you could read the compiler sources, good luck trying to understand any of the top 20 language compilers or interpreters today. We have fallen into the trap of expecting complex compilers to do too much of the work. I am a big fan of interpreters precisely because they should always be able to fit into cache so that the language machine is defined for the problem at hand.
Ok, agile and scrum are NOT bad. Your example shows someone using it very wrong. You never let the customer know the number of story points, that's an internal calculation to help approximate workload, not a selling point for a price package. And I'm not sure at all what you mean by t-shirt sizes. Also, if you are doing an 8 hour sprint planning, that sprint should be 4 weeks. So that's 1 full work day of planning, then you get 27 calendar days to work. Doesn't seem so bad. Stand-ups are only 15 minutes normally, so in an 8 hour day, you still get 7hr 45mins of work. I agree that scrum of scrums are annoying but they normally don't last long and can be done once a week at most. In general, if you didn't have an over zealous management team that loves meetings, scrum can be very advantageous. Don't blame the tool if your organization is using it wrong.
"agile and scrum are NOT bad." Ah yes, the classic "x is not bad, you're just using it wrong"~ The numbers you provided never work in reality, all planning takes so much more, same with stand-ups/daily calls. I'm not trying to sound mean, it's just if a project management system is good, it should not need constant convincing is it good.
@@mllenessmarie it isn't "the classic", it's the truth. If you use a tool wrong, it doesn't work. How is that illogical? The numbers I gave come directly from a company I used to work for and they are accurate. We used scrum successfully and I never felt like I was in meetings more than I was working. I know it can work because I've seen it first hand, and I have many other examples. It's a fact that if you misunderstand how to do something, and you do it wrong because of that, then it doesn't work. Again how is that in any way illogical?
I think what most likely is happening is that upper management reads an article one time about this thing called scrum, thought it was great, and decided to force it on the team without actually fully understanding how to use it properly. The team doesn't know either, so everyone tries to figure it out as they go, thinking they are doing it right. In reality, the scrum master should ensure stand-ups are kept short and sweet (ours were 15 minutes max and the prescribed small team size makes this possible), sprint planning should be no more than 1 to 2 hours per week in the sprint and scrum of scrums is just a quick recap with the heads of each team, happening at most once a week. We did ours at the end of the work day on Friday when everyone was pretty much mentally checked out anyway. Meetings are kept to just what needs to be talked about and those timings are easy to hit when the scrum master is on top of things and keeps everyone on track. Scrum works and you get a lot of work done. Now I've also worked for a company where they seem to love meetings and everyone feels as though work time is suffering because of it. Meetings drag on too long because no one tells people to wrap it up and there are 2 of these a day. This is not scrum, this is just poor time management from the company.
@@pharoah327 It's not that the tool is wrongly used, the tool is faulty from the very beginning. Btw. google "scrum T-shirt sizing" (the thing that surprised you in your first comment) and see how common that silly notion is. Also, I'm really happy that you guys managed to implement it successfully at your company (and as you have some other examples too), but that's anecdotal at best, as it's so more common to see scrum/agile being used incorrectly. So much so that seeing good agile/scrum is like seeing a rainbow - it happens, but it's a rare event. Also, I'm not fluent in project management as I work cybersecurity engineering. I do not need to to know that someone is trying to sell me methodology that is sh*t. Kanban boards? These I know and I respect them as they work great. And other tools used in project management. Same with tracking the updates. So I'm not completely against the idea, I'm just against things that do not work (story points and estimates - always wrong, countless calls and no time for real work, PMs with silly ideas etc.).
@@pharoah327Probably the first time I read someone who groks it - kudos 👍🏻 Although, the sad fact is there are thousands out there who don’t get any of it and the execs are their kings…🤦🏻♂️
Oh yeah! Agile is the worst. I started to work for an agile company almost 2 years ago (still working) and compared to all my non agile years before is that we have so many meetings (1-4h per day). For every small thing: a meeting. For a feature which I could to alone without any distractions in 2 weeks, we have been already working on it for 2 months now. We are over budget and customer is pissed. Because everything needs a damn meeting. Agile should increase the quality of the project, but it is just increasing my blood pressure.
tl;dr 1. What you likely believe is low-level (i.e. "what lies beneath the abstraction"), actually is actually another abstraction (e.g. C is a high-level language, it assumes flat memory and sequential execution) and your model of the computer when programming is a complete abstraction. 2. That model doesn't it contain any unique "first principles" that are necessary for computation. 3. You're likely to just make it harder/impossible for the compiler to optimize your code if you start fucking with "low-level" stuff and micromanaging everything when that's unnecessary. 4. Humans are better at declarative (math-like) reasoning than imperative (Turing machine like) reasoning. Bit twiddling is hard and error prone, and it distracts from the actual problem leading to logic errors being harder to spot amidst all the micromanagement. It's best to leave that stuff to machines, which are good at stuff like that. 5. Since we're all pretending anyway, we should pick the right level of abstraction to pretend depending on the job. Imo, that usually requires a high-level declarative language . AGILE is cancer but I disagree that the issue is higher level languages. Don't get me wrong, I don't think the most popular JS framework at this micro-instant is the best thing ever, I'm approaching this from first principles. I do think thinking about bits in memory and pointers and such is not useful if you're not doing systems level programming, quite the opposite: it's an error prone distraction from the actual problem domain. First of all, C's (and even ASM's) model of the computer isn't really "low-level" unless you're actually programming for the PDP-11. But you're not, you're most likely programming for a different abstract machine, like a web browser. Saying that ppl need to learn "how a computer really works" and they should program that way is pure LARP because that's not how a computer "really works", and you're likely just making it harder for the compiler to optimize your code for modern architectures. Yes, it's good to know C and ASM as a kind of "general education" for any programmer but that's as far as they go for general app development. C is a high-level language and it has many concepts that are pure abstractions, like the call stack (which isn't technically required by the spec but most implementations still have it). These are all useful abstractions for the systems programmer/language designers etc but not all of them (like the call stack) are useful for most programmers. They are also not universal principles for computing, they are often very practical and particular to our actual machines (or rather their predecessors) but unless you're working on the machine itself, you're better off just forgetting all about that stuff. What you really want is to program for an abstract machine on the right "level of abstraction" for whatever it is you're doing, and let the AM handle the hard parts since there's zero chance of you actually being able to do a better job on any non-trivial program. The part of the problem, in my opinion, is the whole imperative mindset that encourages us to pretend that there's a single core executing instructions, one by one, pulled from flat memory (modulo concurrent imperative programming but that's even worse!). And that's the best we can do really because you don't really want to reveal what's "beneath the abstraction", you want the OS and drivers (and actual HW below them) to deal with the messy stuff and pretend that you're programming for the simple PDP-11. Contrast that to declarative code which, in principle, could be parallelized automatically by the compiler (but in reality it's not this simple of course) because in declarative code, you don't care at all about the actual physical machine. Instead, you define a high-level description that compilers, unhindered by your silly ideas of what a computer is, can then turn into an efficient machine code for the actual physical machine (rather than your imagined PDP-11). Humans are bad at programming Turing machines to do complex things, we're a lot better at doing something akin to math, i.e. declarative stuff. In other words, most of us should be looking to lambda calculus for "low-level" first principles rather than actual real world machines. Leave that to the geniuses and compilers to handle.
You don't have to be a genius to do low level coding. Abstractions are good for repetitive tasks, compilers are generally good at optimization, but they can only do static analysis of the code. They do not understand your requirements, and so there are many situations where you'll want to optimize code for a particular situation, particularly when building large applications. Learning how computers work at the low and intermediate levels will make you a better programmer and will help you to debug your programs. You don't need to start out with x86 assembly, but you should get to a point where if you're given the CPU manual and a simple program you can map out the operations that program runs
@@noahw4623 Yes, but when you say learning how computers work on a low level, you're probably talking about a very simplified model that itself is actually a fairly high level abstraction. It's still worth it as general education but it's not how computers work (similarly, I'd say it's good to know basics of theory of computation, a little lambda calculus, formal languages etc). I'd personally recommend getting comfortable with a RISC-V emulator and the classic "Computer Organization and Design" but the RISC-V version. But I claim it won't benefit you in practice unless you develop for RISC-V. And the same goes for x86 and anything else. Have you ever recalled how the processor datapath works when programming for the web? No, because the abstract machine isn't the CPU in this case, it's the browser. That also goes for higher level models like how C models the computer: it's only useful in practice if you write programs with C. Also, the cases where your hand optimized code is better than what a compiler can produce are extremely rare. Unless you're Linus Torvalds, I'd be extremely skeptical of any claims of going against the compiler (not that it's impossible tho). The benefit of declarative (especially functional) code is that it doesn't restrict the compiler as much, you give it more opportunities to optimize. It's true that currently declarative code generally runs at least a little slower than imperative code but I think that'll change in the future, at least for programs that benefit from parallelization. The real benefit is readability/maintainability/extensibility though. Source code isn't so much a common language between the computer and the programmer, but between programmers. Code should be optimized for other programmers and it's the compilers job to make it run efficiently, with obvious exceptions of course.
@@ratfuk9340 Suppose I'm writing a python program for a ML task, and I have a large (several million element) list that I want to sort for some reason. What's better, sorting using the built-in sort algorithm, or writing a module in C++ to do it? C++ would be faster. Now, I could use the builtin sorting function for C++, but this is single threaded, and will be slow. The smarter approach would be to parallelize the sorting operation to speed it up, can your compiler do that without any additional insight? (Hint: it can't) Most of the code I write is backend, desktop, embedded, and server. While your arguments may be true for front end web development, it's not true for programming as a whole.
That is true. Most of them are not good at all. Another topic is mentality. Most of the indian developers go there to be part of the company in that job for 1 to 2 years. If they do not manage to get into management at that time frame they quit.... And then you start over with another freshman. The very good engineers in that country mostly leave anyway to the US or to Europe.
Martin Fowler never having done anything useful is an interesting point. I remember when RMS got his feet out and started moisturising them in the middle of an interview, and, in awe of how little of a fuck he gave, I wondered what he'd done to make him so revered. Turns out he wrote GCC. Moisturise at will.
martin fowler did a good thing in documenting patterns and practices. the issue is actually that people ain’t reading what he and others actually wrote. he’s also not happy, as are kent beck, et al., with what agile has become. the real issue is that the demand for software developers grew so fast that education and science couldn’t keep up and instead we now have something that alan kay called “pop culture”. the whole agile, ddd, clean code thing basically grew out of what alan kay was trying to do: computers which could be programmed by their users. then the internet and java hypes killed it.
@@bitheap-tech 1) Very dogmatic practices (OOP) which brings unmeasurable advantages for cost of performance and quality. 2) Big company only interested in how fast features shipped. They dont care about quality of such features. 3) Bad code in slow languages on top of decedes of legacy code and abstraction. 4) No standards for quality software. People seemenly okay that sites loads welcome page in 10 seconds(!!!!!) same with some desktop apps(vusial studio, visual code)
@@bitheap-tech Because they need to make work for themselves. Everything most always improve even if it is perfectly fine because then you are out with the job. Also, there is obsession with Dev ops processes and automated testing.... but not the actual testing that matters. User testing....
As a software engineer myself, I can confirm that it's usually management who forces us to implement stupid changes... Those few developers who protest, are usually removed from the company...
this is what happens when you're only employed for the project sprint or to develop a product. The next devs have to try figure out wth happened and try fix things that were built wrong, but probably don't have the time to do so, so they just throw their new stuff on top of older and broken stuff, and then the flaky tower built on dolomite ground just keeps growing
i completely agree with the video, but wonder, why software different compared to other engineering jobs? is it because; - it can be "self-taught" - bootcamps pumping people to the sector - agile is not applicable to other engineering jobs - something else?
Probably this combined with the continuous need for companies to get engineers on board to continue access more funding to finance their software projects.
a) software is basically literature. the other engineering disciplines have to cope with much more constraints. b) the demand for software developers has exploded over the last decades so that education couldn’t keep up. which increased the demand even more.
Software engineering is mostly like Golf. It is pretty difficult to get the technique right to be a good golfer. But it does not look like much. And because it does not look like much anyone believes he/she can do it and have a say in that topic.
I think the biggest difference is that it's not physical. If a bridge collapses because the statics were not correctly calculated, if a car loses its wheels while driving, these are all very dangerous and costly faults. On the other hand, if a software crashes - no biggie, restart it and maybe make a bug report and hopefully get a patched version soon. Of course in more critical applications (i.e. aircraft control) software is held to the same standards as hardware and the development and testing is rigorous.
absolutely, and it's Google ffs... almost unlimited money and huge talent in their workforce. And on top of that, they recently increased their pricing for premium
@@bitheap-tech I've had many longstanding bugs in youtube they just refuse to fix, some for over 6 years. Listen to a big music playlist (1000+ songs), for instance, and you'll find it can get stuck in the same loop of 4-8 songs. Last checked a year ago, but it's been a thing for so long I have no doubts it's still there.
Great points! I would add the maintainability dimension to the quality part. It's more common than ever to see non-backwards-compatible software. It's very annoying to normalize such a low standard for delivering software.
I agree completely. Even biggest tech companies create products with unbelievable logical errors. At the end of hundred thousands years of human history, we can not even deliver scroll-consistent websites. Unbelievable. Today’s developers are addicted so much to frameworks, ORMs, packages, abstractions, and componentization that they end up making simple jobs quite harder for the sake of their mottos, such as DRY.
DRY is a cost reducer, so your company doesn't need a programmer with deep knowledge or one can do many things, biblically accurate example is Unity (not a very good piece of code) what can save a lot of money vs handmade game engine what need a really cool guys and tons of time
The greedy industry is trying to move faster than it can, resulting in hiring people who should have never been allowed anywhere close to any engineering (and I mean 99% of those who call themselves programmers these days).
FB has two apps so they can compete in the messenger space; not because the app is too complicated. Games are huge multiple year billion dollar projects that get pushed out the door, not because they're too complicated to make (10 years as a game dev). Banks are complicated because they're built ontop of mainframes from the 1980s and it's a highly regulated space. Look into the tech work Chase has done as an example of tech leadership pivoting an org. Martin Fowler, while I'm not a fan, is a well established author for longer than you've been an engineer. Coming from someone with 20+ years in software engineering: The rest of your rant is pretty mediocre and comes off amateurish; seemingly with little real world org and software scaling experience.
I appreciate your input, but: 1. For iOS FB didn't do the same, and they have significantly bigger competition there. 2. Don't understand your argument. Does this justify having 0-day patches? 3. Not true. The app I was talking about is written in JS, powered by a node js server. Ofc payments are still reliant on mainframes, but that's the only reliable part of this app, not the feedback form I was referencing. 4. Well established in cult companies, you are correct! Although I find his refactoring snippets from his books valuable, they are still refering to the Animal class famous examples from OOP. Nothing capturing a real software that brings real value. Also, introducing endless debates about what a test name should be does not make you well-established IMHO. We're not/should not be epistemologists here, we are engineers.
With the way things are going, I can foresee moves to at least roll back the complexities somewhat, by shifting some functionality away from the cloud, and deploying critical assets MUCH closer to home for one. And two, some kind of hybrid approach between monoliths and microservices. I.e. rolling back an INSANE system, built upon stupid amounts of tiny chatty microscopic services, to one more inline with the actual structure of the company itself. With each (macro?) service being maintained by a dedicated full-stack team of frontend, backend and database coders, who will not only be SOLEY responsible for the service in question, but any other infrastructure associated with it, such as their own dedicated databases, and development and staging environments. And to help facilitate orchestration with other teams, and other services, using ONE centralised messaging service, along with ONE centralised logging system to log issues in such a way, that ONLY the teams that need to get involved, will be alerted. Bottom-line, we just need LESS complexity, more consolidation and more logical organisation, in order to build and maintain systems which don't look like they were built by NASA or something! Not for systems as straightforward as a simple web application! Case in point, my last company housed around 1200+ repos, along with a few hundred microservices, ALL on MULTIPLE cloud systems, with multiple databases, logging and message queues. ALL this... For a simple crowdfunding / fundraising online charity website... WHY??? For the LOVE of God... WHY??? Anyway, even reasonable suggestions like these, will only merely scratch the surface because we also have serious issues with our package management systems, chock full of security loopholes, BAD code and exploits, all in the spirit of open-source software! And we also have a growing skills shortage, that misguided individuals claim, will be mitigated by AI! So yeah... We HAVE a serious and growing problem in this industry! An industry which now effectively runs this planet!
I'll add maintainability to the software quality definition... and there the "all in python crowd" really hurts ! v2 to v3 was a pain, but it doesn't end here: 3.6 to 3.10 is a mess too ! And maybe worst, the way variables are "defined" make any refactoring a nightmare. So please use python only to replace shell scripts or little tools...
