a dev video with a thumbnail of the joker (the lame joker) is an instant 'do not recommend channel' from me. Might as well give me a tier list or the iceberg of being an idiot.
I code like this - 1st create a dirty and working code , then refactor it to a stage that my future me can understand. i found this method actually makes me more productive as watching something works drives more motivation than watching something clean fail
+1 on this. Exactly how I work and find productivity. Create something functional ASAP and iterate. And whenever code become to complicated, it is a good indication that thing are not working out and it's time to start think about major refactor. Is this a good/best approach? Perhaps not, but have been serving me just fine.
I code like this - 1st create a dirty and working code, send it to the QA team to meet the deadline, and then never get the chance to get back to refactoring it to a stage that my future me can understand.
in our company, we use microservices and the biggest problem is that the microservices are dependent on each other. We change something in service A, we break service B..., we don't use versioning for the API endpoints. It is basically a distributed monolith. And it is a pain to work on such a cluster fuck locally
exactly the big issue, coupling and cohesion go hand in hand. domain driven is, in my opinion, the only way to model such a distributed system. if it has cohesion it should have coupling - decoupling isn’t a must - it actually can be a problem
My favorite thing is to go through 4 microservices to do a simple database update. My second favorite thing is to implement distributed transactions over microservices.
Dude, this is the brute and cold blood true of the 100% of the IT/Dev Jobs, Clients, Projects and People in the Industry, thanks for put it in the right words with best examples too. Keep doing this Awesome work you do.
TLDW: Lie 1.: You need to worry about scalability (0:55) Lie 2.: Big tech implies competency (3:04) Lie 3.: Serious development has to be complex (4:48) Lie 4.: Software quality matters (6:11) Lie 5.: You'll be replaced by AI (7:42)
I believe we should "pursue" around 80% of clean code and best practices. DRY is always a point of concern for me. Early in my dev life I abstracted things as much as I can. ~99% DRY, but also hella unreadable. Nowadays I always remind myself that repeated code maybe 2-3 times is OK and nice to read. When the exact same lines are used repeatedly across multiple files, then maybe its time to extract it to its own function/constant.
@@antoniong4380 It only matters if the repeated code is a business logic / behavior that needs to be consistent across the solution. Otherwise, KISS. Time to market is more important in many cases.
One of the hardest parts of handling a large monolith for me was trying to update packages. The larger the project the harder it becomes even to the point of becoming impossible.
I was involved in a project where that was the case. They are just now getting away from Java 8 to a newer verison. In my experience this also happens because updating packages is not always a priority, but it should be. Once you are ignoring it for a couple of years, it's pretty much impossible to do the updatess.
@@awesome-coding lol, the company I'm at now hasn't even had developers working on the project I am working for the past couple of years. It's been on auto pilot. And, yes, it is a pain to work on without having any other developer to talk to that has previously worked on it. And the tech that was used I don't particularly care for (node and react - I prefer .NET and HTMX). But it has been fun to go through everything and update things.
@@awesome-coding THIS. Ubiquiti's UNIFI controller, the thing that manages your ENTIRE BUSINESS NETWORK INFRASTRUCTURE requires you to install a severely outdated version of JAVA... Think about that for a second from a security perspective. Entire. Network. Controller.
Another lie that clean code guarantees good application, when in reality it can cause either too many levels of abstractions or bad performance of the application. It doesn't mean that "clean code" and "bad practices" absolutely useless, but they should be used with careful consideration. Basically: "Does X rule really makes my job easier and my app more stable or faster"?
While a buggy software that provides great customer value is better that a clean standardized code base with little or no value to customers. The best of all is a clean standard code base that provides great value to end users.
I think that we need to talk more about this kind of topic. Because I feel that the online discourse about software development gravitates too much around languages, editors, libraries, and tools. E.g. your favourite language will not prevent you to store passwords on plain text.
Yep - agreed :) The reality is that production code is a mess in 99% of the cases, but YT content is all about enforcing the best practices in a TODO app :))
Also, the amount of tech-specific discourse may have a negative impact on people looking to change job. I'm only a few years into my career and I'd love to change technology but it's hard to convince a recruiter I can manage a shift even to a language very similar to the one I use day in and day out.
3 is totally true, the company where I work has a app that is a messy soup of JSON manipulation with endless layers. I’ve spent time debugging open source projects that does way more complex stuff with less layers
I am still learning the basics of programming - web dev specifically - and always doubting myself if I ever become a competent and marketable dev one day given that I'm near 40 and I always forget what I learned. But what you're sharing at 3:41 makes me get my hopes up again.
Dont be too hard on yourself, give yourself time with more practice, by a year or two you will be shocked at how good you are. Actually you will be more surprised by how many things you actually know.
@@josephmgift/videos Yeah I think I kinda got that feeling now given I have been studying programming on and off for almost 6+ months now. Thank you for the encouragement!
20m users isn't really that many anyway, but it's B2C so you might have heard of it. There are a lot of B2B that are much bigger that you've probably never heard of. I would have thought doordash would be bigger though. Microservices do solve a scalability problem, but it's mostly for scaling your dev team not your users.
We have to have lots of meetings, and poker planning, and sprint planning, sprint meetings, retrospect meetings. Nobody cares about updating dependencies and it is risky to do so since it can cause breakage and then you get yelled at. Our frameworks are end-of-life and unsupported, our dependencies contains security vulnerabilities. Nobody cares about fixing security vulnerabilities, because it doesn't deliver business value or customer value.
@@awesome-coding No, I am paid horribly bad. I am also scared to seek another because I have no idea how it would be, if it would be good or bad, and that scares me. Also at this job I am still employed even after arriving late more times than is okay, and after all the stupid things that have come out from my mouth.
@@fred.flintstone4099 Sorry to hear. But, at the end of the day, as long as you have a good enough work life balance and are happy that's all that matters
Not so long ago I heard in a video that generally speaking we shouldn't obsess over simplicity because a production code base shouldn't be too simple or otherwise it will be too resistant to change In other words, you should aim your code to be simple, but not simpler
google got the shittiest front end, how come ? just use firebase, the responsiveness is soo bad, I don't believe the hype around those tech giants anymore. you only need the idea everything else can be solved.
Neglecting code quality down the road leads to hard to maintain software with bugs popping out all the time due to patch on opt of patch on top of patch
I agree, but most company are willing to kick the can down the road and test their product and ideas with poorly written code and the promise that "we'll rewrite this later". However this rarely happens.
To be very clear, during the interview he never said that "micro-services don't help solve scaling". He did very clearly state "micro-services aren't about scaling". Some good patterns exist in the realm for scaling. That doesn't mean it's easier. That doesn't make it any more effective. Just that the patterns are well-known.
I agree. The point I was trying to make was that if these guys don't need microservices to scale, your random average joe working on a B2B product in a 10 men team for certain don't need to complicate their life with them :)
Its not even about it being one codebase. You can have a full monorepo and still have microservices (see google or Facebook) the real issue is deployment pipelines
I believe devs who use other software are usually "power users". In the sense that you will always pay attention to details non technical people don't really care about.
"...The software I'm using..." See! You are using it. From the business perspective, it already fulfilled it's purpose & good quality wasn't even necessary.
@@deado7282 Either that or it has an effective monopoly. At work I am required to use Windows 11. Do I want to? no. Do I enjoy all the times it randomly freezes? Also no. Does it impress me that Microsoft Teams crashes on a regular basis? Again, not in the slightest. IMO if you want stable software, go for some open-source stuff that's been around since the 90s. It might not be the flashiest software in the world but it's frequently rock-solid.
I understand, and I agree with you from the developer perspective. On the business perspective however, they rarely care. They want the product our as soon as possible, and they are willing to compromise on software quality. In the world of fast, cheap and quality, quality will most of the time come last in software.
The AI part I don't disagree, I just think that the tone is not quite right. I mean, it will not be like a jetbrains new tool. It will be (it is actually) REALLY disruptive. It will change the industry in deep ways. I don't know if it will not replace developers since I can't say what will be changed. But yeah, many will be replaced. The generator technology itself will lead us to the next industrial revolution. I mean, it's not a new tool, it's a new craft mindset. I'm not an alarmist, but I don't agree with the "just continue do what you're doing" tone. The way I see it there's 3 spectrum trends of Devs around this theme, they have some level of those traits: The emotional, who just got into this train and it's impressed but can't do something really productive with it; Who don't know how to use it, do nothing and think it is like a new tool; and who achieved some kind of knowledge on how to be productive with it, use it in a daily basis, see the weekly updates of that and can perceive the clear improvement of many aspects of the process. The dev will not be replaced is a true statement IMO, but I'm not so sure about how much change the craft can take and still be considered [in contrast to the developer capabilities] the same thing.
Is this the reason group people are not working together as there cost for correct way to manage the web? I guess faster the build to release to site stable is faster to find bugs and loop holes.
2:10 If someone mentions that you need scalability for your 10 users, run from this person What is better for scalability than microservices? Which architecture would you suggest?
A well written monolith will be enough to scale for 99.9% of use cases. Microservices are actually not solving the scaling problem, they are solving the code collaboration and deployment problem.
8:20 I do not agree. Generalists will be replaced by an AI. It is people who are very deep down in something who have higher changes of survival. They know very obscure things and can for example write extremely efficient code in a specific scenario. AI is good for quick overview, templating etc. If you want to build a basic page that generalist could do, then AI will easily solve that problem for someone non-technical. But if the problem is very complex or niche AI will not be good enough.
You are saying that Doordash switched to microservces not for scalability but because it was easier to work on with multiple devs. Then, you somehow conclude that microservices are not about scalability? This is not a correct logical inference. It's like saying "I chose banana because it's yellow. Therefore bananas aren't sweet."
The Doordash engineer said they migrated to microservices because of issues with releases and large team collaboration. He said that doordash, who serves 10s of millions of clients was just fine with a monolith to handle all that load. So the conclusion is that choosing microservices for scalability reasons, meaning being able to handle large amounts of traffic is not a good idea. Microservices are more of an organisational solution which actually creates technical debt.
@@awesome-coding This is not logically sound. The right conclusion is, that people can choose to migrate to microservice architecture for other reasons, unrelated to scalability. For scalability the only conclusion you can make from the doordash story is, that the scalability of microservices was also good enough for them. Otherwise they wouldn't have used it. See my banana example. I think it captures the logical mistake, that you're making.
You're misunderstanding the point of code quality. Code quality isn't a value deliver on its own, but what it does is allow you to effectively deliver new features or modify existing ones at speed, to let you respond to those market demands
Actually, software quality matters. Stop lying. Sometimes, when someone says software quality doesn't matter either A.) They are stuck on that software B.) The software has some kind of monopoly C.) Etc Contrast that with software which needs to be good and have quality. Because of competition.
I know of a "little" company I intersected with in 2016 which was handling restaurant reservations for tens of thousands of customers in one of the biggest markets in the world, and they were storing a bunch of their data in plain text files because they started with an MVP from the 2000s where they thought a database was not that important. :) To your point, if that software has some kind of monopoly it means that it was "good enough" for the majority of customers and use cases. So the quality of that software did not matter in the equation.
@awesome-coding Idk what the context this have, but could have that "little" company have changed software if they are given the chance and resources? , or are they satisfied with the "good enough" software they have?
The thing is, every great developer was average or bad before. So if AI replaces bad and average developers, there will be no new good developers any more.
I'm not sure who this "we" is, but my colleagues are still building B2B apps with microservices even though they only need like 4 engineers. Maybe that's why te economy got so bad...
Thanks to Jam for sponsoring this video!
Try jam.dev if you want to spend your time coding rather than responding to Jira comments.
You made a fantastic point about simplicity. It's HARD to achieve.
a dev video with a thumbnail of the joker (the lame joker) is an instant 'do not recommend channel' from me. Might as well give me a tier list or the iceberg of being an idiot.
@@webdesignsbytom your logo looks like the wacky inflatable tube man.
@@NickTheCodeMechanic is that meant to be bad?
I code like this - 1st create a dirty and working code , then refactor it to a stage that my future me can understand.
i found this method actually makes me more productive as watching something works drives more motivation than watching something clean fail
+1 on this. Exactly how I work and find productivity. Create something functional ASAP and iterate. And whenever code become to complicated, it is a good indication that thing are not working out and it's time to start think about major refactor. Is this a good/best approach? Perhaps not, but have been serving me just fine.
Underated comment! this is me all the time 😂
I code like this - 1st create a dirty and working code, send it to the QA team to meet the deadline, and then never get the chance to get back to refactoring it to a stage that my future me can understand.
@@awesome-coding this is the truth, lol
I have learned this: to stop perfecting my code and focus on what the user really wants.
The secret to success and a happy life :D
What user?
I still struggle with this
"Users' expectations and needs"? What artifact is that? Can you make a Jira ticket for it?
But if your code is shit, you'll suffer when maintaining or scaling. Only anyone who works in toy projects says something like that.
in our company, we use microservices and the biggest problem is that the microservices are dependent on each other. We change something in service A, we break service B..., we don't use versioning for the API endpoints. It is basically a distributed monolith. And it is a pain to work on such a cluster fuck locally
One of us 🙏
exactly the big issue, coupling and cohesion go hand in hand. domain driven is, in my opinion, the only way to model such a distributed system.
if it has cohesion it should have coupling - decoupling isn’t a must - it actually can be a problem
My favorite thing is to go through 4 microservices to do a simple database update.
My second favorite thing is to implement distributed transactions over microservices.
@@awesome-coding The Third favourite thing is to explain why microservices are the best to my manager
@@nithinrajendran3091 You should also try listening to your non technical manager explaining why microservices are superior :D
Dude, this is the brute and cold blood true of the 100% of the IT/Dev Jobs, Clients, Projects and People in the Industry, thanks for put it in the right words with best examples too.
Keep doing this Awesome work you do.
Thank you!
TLDW:
Lie 1.: You need to worry about scalability (0:55)
Lie 2.: Big tech implies competency (3:04)
Lie 3.: Serious development has to be complex (4:48)
Lie 4.: Software quality matters (6:11)
Lie 5.: You'll be replaced by AI (7:42)
❤
Edit this with timestamps.
👍🏻
Good job.
@@nexovec Wow.
Time stamps are there so quickly.
Appreciate. 👍🏻
@@VirendraBG You're welcome
I believe we should "pursue" around 80% of clean code and best practices.
DRY is always a point of concern for me. Early in my dev life I abstracted things as much as I can. ~99% DRY, but also hella unreadable. Nowadays I always remind myself that repeated code maybe 2-3 times is OK and nice to read.
When the exact same lines are used repeatedly across multiple files, then maybe its time to extract it to its own function/constant.
Fair enough
I think the same, but this ideology breaks once you forget where else something repeats.
@@antoniong4380 It only matters if the repeated code is a business logic / behavior that needs to be consistent across the solution.
Otherwise, KISS. Time to market is more important in many cases.
please keep this channel going. your takes and subject choices are a breath of fresh air.
Thank you for the nice words!
One of the hardest parts of handling a large monolith for me was trying to update packages. The larger the project the harder it becomes even to the point of becoming impossible.
I was involved in a project where that was the case. They are just now getting away from Java 8 to a newer verison.
In my experience this also happens because updating packages is not always a priority, but it should be. Once you are ignoring it for a couple of years, it's pretty much impossible to do the updatess.
@@awesome-coding lol, the company I'm at now hasn't even had developers working on the project I am working for the past couple of years. It's been on auto pilot. And, yes, it is a pain to work on without having any other developer to talk to that has previously worked on it. And the tech that was used I don't particularly care for (node and react - I prefer .NET and HTMX).
But it has been fun to go through everything and update things.
@@awesome-coding THIS. Ubiquiti's UNIFI controller, the thing that manages your ENTIRE BUSINESS NETWORK INFRASTRUCTURE requires you to install a severely outdated version of JAVA... Think about that for a second from a security perspective. Entire. Network. Controller.
Another lie that clean code guarantees good application, when in reality it can cause either too many levels of abstractions or bad performance of the application. It doesn't mean that "clean code" and "bad practices" absolutely useless, but they should be used with careful consideration. Basically: "Does X rule really makes my job easier and my app more stable or faster"?
The only thing worse than CLEAN Code are Uncle Bob’s politics.
While a buggy software that provides great customer value is better that a clean standardized code base with little or no value to customers. The best of all is a clean standard code base that provides great value to end users.
I think that we need to talk more about this kind of topic. Because I feel that the online discourse about software development gravitates too much around languages, editors, libraries, and tools. E.g. your favourite language will not prevent you to store passwords on plain text.
Yep - agreed :)
The reality is that production code is a mess in 99% of the cases, but YT content is all about enforcing the best practices in a TODO app :))
Also, the amount of tech-specific discourse may have a negative impact on people looking to change job. I'm only a few years into my career and I'd love to change technology but it's hard to convince a recruiter I can manage a shift even to a language very similar to the one I use day in and day out.
3 is totally true, the company where I work has a app that is a messy soup of JSON manipulation with endless layers. I’ve spent time debugging open source projects that does way more complex stuff with less layers
I am still learning the basics of programming - web dev specifically - and always doubting myself if I ever become a competent and marketable dev one day given that I'm near 40 and I always forget what I learned.
But what you're sharing at 3:41 makes me get my hopes up again.
Gad to hear! Good luck with your journey!
Dont be too hard on yourself, give yourself time with more practice, by a year or two you will be shocked at how good you are. Actually you will be more surprised by how many things you actually know.
@@josephmgift/videos Yeah I think I kinda got that feeling now given I have been studying programming on and off for almost 6+ months now.
Thank you for the encouragement!
20m users isn't really that many anyway, but it's B2C so you might have heard of it. There are a lot of B2B that are much bigger that you've probably never heard of. I would have thought doordash would be bigger though.
Microservices do solve a scalability problem, but it's mostly for scaling your dev team not your users.
Great video, just subscribed to your channel! I really like the shorter video format.
Thank you!
Amazing video, the doordash example makes it more clear
Thank you!
We have to have lots of meetings, and poker planning, and sprint planning, sprint meetings, retrospect meetings. Nobody cares about updating dependencies and it is risky to do so since it can cause breakage and then you get yelled at. Our frameworks are end-of-life and unsupported, our dependencies contains security vulnerabilities. Nobody cares about fixing security vulnerabilities, because it doesn't deliver business value or customer value.
It sounds like you are paid pretty well :D
@@awesome-coding No, I am paid horribly bad. I am also scared to seek another because I have no idea how it would be, if it would be good or bad, and that scares me. Also at this job I am still employed even after arriving late more times than is okay, and after all the stupid things that have come out from my mouth.
It sounds like you're burnt out and have lost all motivation. You need to find another job. You're a lot better than you think you are.
@@fred.flintstone4099 Sorry to hear. But, at the end of the day, as long as you have a good enough work life balance and are happy that's all that matters
Not so long ago I heard in a video that generally speaking we shouldn't obsess over simplicity because a production code base shouldn't be too simple or otherwise it will be too resistant to change
In other words, you should aim your code to be simple, but not simpler
Good point!
Quality and time depend on the knowledge and experience of the software developer, as in any other profession.
FAANG COMPANY have very talent people but not all people have that level of talent
right but they have processes in place where talented people are usually supervising the less experienced / talented colleagues
google got the shittiest front end, how come ? just use firebase, the responsiveness is soo bad, I don't believe the hype around those tech giants anymore. you only need the idea everything else can be solved.
4:41 "Remember, competency doesn't come from scale. It comes from consistently getting the fundametals right"
Easy stuff, right? :))
Neglecting code quality down the road leads to hard to maintain software with bugs popping out all the time due to patch on opt of patch on top of patch
I agree, but most company are willing to kick the can down the road and test their product and ideas with poorly written code and the promise that "we'll rewrite this later". However this rarely happens.
To be very clear, during the interview he never said that "micro-services don't help solve scaling". He did very clearly state "micro-services aren't about scaling".
Some good patterns exist in the realm for scaling. That doesn't mean it's easier. That doesn't make it any more effective. Just that the patterns are well-known.
I agree. The point I was trying to make was that if these guys don't need microservices to scale, your random average joe working on a B2B product in a 10 men team for certain don't need to complicate their life with them :)
Specialisations is for insects 😂
educated comment ever
Bugs!!!
Its not even about it being one codebase. You can have a full monorepo and still have microservices (see google or Facebook) the real issue is deployment pipelines
Yep - that release train is killing us all :D
From 🇧🇩, Thank you
I as a user care about software quality. The software I'm using now-a-days are poo poo
I believe devs who use other software are usually "power users".
In the sense that you will always pay attention to details non technical people don't really care about.
Do you have any comparables in mind?
"...The software I'm using..."
See! You are using it. From the business perspective, it already fulfilled it's purpose & good quality wasn't even necessary.
@@deado7282 Either that or it has an effective monopoly. At work I am required to use Windows 11. Do I want to? no. Do I enjoy all the times it randomly freezes? Also no. Does it impress me that Microsoft Teams crashes on a regular basis? Again, not in the slightest.
IMO if you want stable software, go for some open-source stuff that's been around since the 90s. It might not be the flashiest software in the world but it's frequently rock-solid.
Agree with all but quality of code, i can compromise on the later features code, but the foundation must be solid.
I understand, and I agree with you from the developer perspective.
On the business perspective however, they rarely care. They want the product our as soon as possible, and they are willing to compromise on software quality. In the world of fast, cheap and quality, quality will most of the time come last in software.
@@awesome-coding Until they need to pay a $100M fine.
The problem is that the business side often is reactive (and not pro-active). It's a fine line.
I keep saying: What defines a senior developer is to know where to draw the line of "good enough".
@@tcurdt Very well said!
Bravo for pointing out the micro-service reality.
Thank you!
I'm glad that the monolith is having a comeback.
The AI part I don't disagree, I just think that the tone is not quite right. I mean, it will not be like a jetbrains new tool. It will be (it is actually) REALLY disruptive. It will change the industry in deep ways. I don't know if it will not replace developers since I can't say what will be changed. But yeah, many will be replaced. The generator technology itself will lead us to the next industrial revolution. I mean, it's not a new tool, it's a new craft mindset. I'm not an alarmist, but I don't agree with the "just continue do what you're doing" tone. The way I see it there's 3 spectrum trends of Devs around this theme, they have some level of those traits:
The emotional, who just got into this train and it's impressed but can't do something really productive with it; Who don't know how to use it, do nothing and think it is like a new tool; and who achieved some kind of knowledge on how to be productive with it, use it in a daily basis, see the weekly updates of that and can perceive the clear improvement of many aspects of the process.
The dev will not be replaced is a true statement IMO, but I'm not so sure about how much change the craft can take and still be considered [in contrast to the developer capabilities] the same thing.
Microservices does not mean multi repo. You can still do them in a monorepo.
Yep :)
Bro fourth lie is not a lie, clean code and common practices are very important, even AI gives better enhancements within clean environment
They are important for us developers. Business doesn't car about clean code :)
Yeah sign! Here is a book about this thing (it's not IT specific) called: Range: How generalists triumph in a specialized world from David Epstein.
Thanks for the suggestion!
Only CI/CD will save you
That and God :))
And my boss yells at me when I commit something that fails to build on CI. Why do we even have CI?
Banger
Thank you!
Is this the reason group people are not working together as there cost for correct way to manage the web? I guess faster the build to release to site stable is faster to find bugs and loop holes.
2:10 If someone mentions that you need scalability for your 10 users, run from this person
What is better for scalability than microservices? Which architecture would you suggest?
A well written monolith will be enough to scale for 99.9% of use cases.
Microservices are actually not solving the scaling problem, they are solving the code collaboration and deployment problem.
treat code as a means to an end which you may or may not work on in the future
Nice!
Clean code doesn't matter, so that's why you hire contractors to clean them
Fact! :))
I the issue with monoliths is code related, then we should just make better tools to make it easy to make changes to a monolith
"I'm expecting to put out a PR this afternoon"
:)) You should request merge privileges and deploy that baby directly to prod! Have a fun weekend!
8:20 I do not agree.
Generalists will be replaced by an AI. It is people who are very deep down in something who have higher changes of survival. They know very obscure things and can for example write extremely efficient code in a specific scenario.
AI is good for quick overview, templating etc. If you want to build a basic page that generalist could do, then AI will easily solve that problem for someone non-technical. But if the problem is very complex or niche AI will not be good enough.
Thank you
Welcome!
It depends
awesome channel jus like the name.
Thank you sir!
If AI doesn't end up taking my job in the future, it isn't finished yet.
😅 Hey.. we can always go back to raising chickens and work the land...
You are saying that Doordash switched to microservces not for scalability but because it was easier to work on with multiple devs. Then, you somehow conclude that microservices are not about scalability? This is not a correct logical inference.
It's like saying "I chose banana because it's yellow. Therefore bananas aren't sweet."
The Doordash engineer said they migrated to microservices because of issues with releases and large team collaboration. He said that doordash, who serves 10s of millions of clients was just fine with a monolith to handle all that load. So the conclusion is that choosing microservices for scalability reasons, meaning being able to handle large amounts of traffic is not a good idea. Microservices are more of an organisational solution which actually creates technical debt.
@@awesome-coding This is not logically sound. The right conclusion is, that people can choose to migrate to microservice architecture for other reasons, unrelated to scalability.
For scalability the only conclusion you can make from the doordash story is, that the scalability of microservices was also good enough for them. Otherwise they wouldn't have used it.
See my banana example. I think it captures the logical mistake, that you're making.
The microservice is just for devs to use fancy words and then ask for better payments.
Yep! A whole new stack you have to learn and put in your resume.
i
Shame!
@@awesome-coding xD
awesome, what do you think about the new joker movie?
Don't get me started! Let's just say I hope they don't make a 3rd one :)
Somehow I think the meta "mistake" wasn't a mistake :DD
Well you might be right. After all they are a pretty evil company :))
@@awesome-coding The Zuck be like "oopsie, you're saying I had to hide your password so that I can't access it, oopsie doopsie 👉👈"
@@robinzon100 Exactly... Now he's probably like "ok guys, please make it so it looks like we are hiding passwords from now on"
that dev of the future 🤣
that's all of us 😅
You're misunderstanding the point of code quality. Code quality isn't a value deliver on its own, but what it does is allow you to effectively deliver new features or modify existing ones at speed, to let you respond to those market demands
Very few people understand this. It's the same thing with testing:
You do it to move faster. If it slows you down - you are doing it wrong.
I thought you renamed your channel to DENO XDDDDDDDDDD
Haha :))
good
Thanks
Actually, software quality matters.
Stop lying.
Sometimes, when someone says software quality doesn't matter either
A.) They are stuck on that software
B.) The software has some kind of monopoly
C.) Etc
Contrast that with software which needs to be good and have quality.
Because of competition.
I know of a "little" company I intersected with in 2016 which was handling restaurant reservations for tens of thousands of customers in one of the biggest markets in the world, and they were storing a bunch of their data in plain text files because they started with an MVP from the 2000s where they thought a database was not that important. :)
To your point, if that software has some kind of monopoly it means that it was "good enough" for the majority of customers and use cases. So the quality of that software did not matter in the equation.
@awesome-coding Idk what the context this have, but could have that "little" company have changed software if they are given the chance and resources? , or are they satisfied with the "good enough" software they have?
Can we Build a Browser in Rust and make JS or Similar Compiled language work with it ?
Why the Heck JS is so weird ?
You can compile Rust into WebAssembly and run it in the browser. Either that, or you can transpile TypeScript into JavaScript.
I thibk AI will replace bad and average developers and that's the most of us
😅 can't wait!
The thing is, every great developer was average or bad before. So if AI replaces bad and average developers, there will be no new good developers any more.
We must become one with the AI. When we can say "I am the AI" then we shall overcome it.
2:10 😂❤
Father, forgive them, for they do not know what they are doing.
Jesus Christ.
😅 It's really easy - trust me bro!
wow first
✌️
Did the economy get this bad so that now we need videos for what we knew all this time? 😂
I'm not sure who this "we" is, but my colleagues are still building B2B apps with microservices even though they only need like 4 engineers.
Maybe that's why te economy got so bad...