A lesson that I learned the hard way: There is no "right way". Avoid premature optimisations! The first example works perfectly fine without even requiring any JavaScript. When you need to change it, you'll easily see all places that need to be adjusted at the same glance. Adjusting multiple lines at the same time is almost no work, especially with the right IDE. As long as all the lines to change are obvious, you don't introduce any technical debt! The architecture is simple and flexible. But what about the second example? You bake the assumption that the texts might change while the classes stay the same into the architecture. Now, if your customer decides that one of the buttons needs custom markup, what are you going to do? You'll need to refactor, maybe create a second array with class names, or maybe create an array of objects that hold the text and the class names? But what about the class names that are the same? Maybe spend some time figuring out the "default" classes and a way to add custom ones and remove some of the default ones? What about other extra markup? Maybe, you want an icon before one of the texts, maybe some additional accessibility attributes? You made it much harder to implement all of these changes. With the first example, it would have been easy! Don't waste your time thinking about extensibility you don't need! You'll make your code more prone to break and harder to maintain in the long run, and also less performant in most cases.
I agree with the sentiment of the video but I disagree with the example. The option on the left is the simplest and optimal solution to this problem. If you need to change a style you can find and replace within your selection. No worries. The option on the right adds complexity for no gain. Premature optimisation is often the enemy of good software. Let's say that you have a second page that requires navigation. A common error is to copy and paste the link list on the left. This is makes the codebase worse. You have now duplicated styles and functionality between components. It increases work as changes need to be done in two areas. It increases the risk of a bug as you may not realise the change must be done in two places.. At this stage, you would want to create a NavigationLink component to encapsulate the styling and functionality. The option on the right in the video would be suitable for dynamic pages and again, you would likely use a NavigationLink component. Like I said, I agree with the general video premise. I just feel it would be better expressed by demonstrating how developer decisions can help/hinder the maintainability of software as navigation evolves. I feel the static example in the video misses the wider point. Thanks for posting the video. It was well presented and generally enjoyed it 👍
Nice vid Ryan, although as mentioned below I'd agree that neither way is the right way. It's great to demonstrate different ways of implementing things though.
You know, if you're working for just yourself, then what you said in this video, is correct. However, you need to put into account, that most developers work for companies. And this is where the problem truly arises. CEOs, for the most parts, they don't care about the quality of your code, they just want "fast food" software. I ain't lying here, this is a very well known fact. Just like in this video, it showed that good things take time to master. But CEOs, they don't "take time" to do crap. Therefore, most developers learned the cold, hard truth that they have to adapt to the way CEOs work, to code faster, better, in order to "race" with the speed of the CEOs. It's the "rat race" after all. Unless the CEOs change their ways of doing things, if not, I bet, more and more developers will continue to do exactly what you told them not to.
This feels a bit out of touch and passing the blame. Maintainability is important because it affects the company's bottom line. If it doesn't produce business value then you're making a bad decision in your project. If there's pushback from management then it is the responsibility of the engineers to translate how maintainability translates into future improved throughput. I get it that there's often dysfunction on software projects, but engineers need to advocate effectively too, so that non technical stakeholders are on the same page.
@@PlerbyMcFlerb "Feel"???? Buddy, because you "feel", that's why you don't understand the fact. If I, as a team leader, made bad decisions, then that is nobody's fault, but mine. However, posting fake jobs(Which are plenty), lying to employees, this thing is real and employers do that all the time. Keep in mind, employers lie to employees all the time and they do that by hiring an entire HR department to do so for them. This is not what I "feel" or "imagine", this thing is real out there. I have witnessed this lying thing between both employers and employees day in and day out, I also see insane job posting without logical sense, such as "5 years of experience" for "junior developers", even more for senior developers, on a daily basis. You see, blaming other or blaming yourselves, that s*** is easy. But, understanding clear whose faults it belongs to, is the hard part. I don't deny the fact that developers also have mistakes and bad habits. But they are not the ones who started the whole thing. The employers do. If the higher ups are liars, then the bottom down will follow.
@@PlerbyMcFlerb Management is hiring profesionals to do their job, maybe don't ask professionals to explain everything they are doing and why they are doing it, because you hired them to do a job, let them do the bloody job
A lesson that I learned the hard way: There is no "right way".
Avoid premature optimisations!
The first example works perfectly fine without even requiring any JavaScript. When you need to change it, you'll easily see all places that need to be adjusted at the same glance. Adjusting multiple lines at the same time is almost no work, especially with the right IDE. As long as all the lines to change are obvious, you don't introduce any technical debt! The architecture is simple and flexible.
But what about the second example? You bake the assumption that the texts might change while the classes stay the same into the architecture. Now, if your customer decides that one of the buttons needs custom markup, what are you going to do? You'll need to refactor, maybe create a second array with class names, or maybe create an array of objects that hold the text and the class names? But what about the class names that are the same? Maybe spend some time figuring out the "default" classes and a way to add custom ones and remove some of the default ones? What about other extra markup? Maybe, you want an icon before one of the texts, maybe some additional accessibility attributes?
You made it much harder to implement all of these changes. With the first example, it would have been easy!
Don't waste your time thinking about extensibility you don't need! You'll make your code more prone to break and harder to maintain in the long run, and also less performant in most cases.
Multiline edits for the shortcut example = shortcutception.
I agree with the sentiment of the video but I disagree with the example.
The option on the left is the simplest and optimal solution to this problem. If you need to change a style you can find and replace within your selection. No worries. The option on the right adds complexity for no gain. Premature optimisation is often the enemy of good software.
Let's say that you have a second page that requires navigation. A common error is to copy and paste the link list on the left. This is makes the codebase worse. You have now duplicated styles and functionality between components. It increases work as changes need to be done in two areas. It increases the risk of a bug as you may not realise the change must be done in two places.. At this stage, you would want to create a NavigationLink component to encapsulate the styling and functionality.
The option on the right in the video would be suitable for dynamic pages and again, you would likely use a NavigationLink component.
Like I said, I agree with the general video premise. I just feel it would be better expressed by demonstrating how developer decisions can help/hinder the maintainability of software as navigation evolves. I feel the static example in the video misses the wider point.
Thanks for posting the video. It was well presented and generally enjoyed it 👍
But what if I want to change just one of the cells colour
Nice vid Ryan, although as mentioned below I'd agree that neither way is the right way. It's great to demonstrate different ways of implementing things though.
Is that tailwind? Looks horrible...
DRY
You know, if you're working for just yourself, then what you said in this video, is correct.
However, you need to put into account, that most developers work for companies. And this is where the problem truly arises.
CEOs, for the most parts, they don't care about the quality of your code, they just want "fast food" software. I ain't lying here, this is a very well known fact.
Just like in this video, it showed that good things take time to master. But CEOs, they don't "take time" to do crap.
Therefore, most developers learned the cold, hard truth that they have to adapt to the way CEOs work, to code faster, better, in order to "race" with the speed of the CEOs. It's the "rat race" after all.
Unless the CEOs change their ways of doing things, if not, I bet, more and more developers will continue to do exactly what you told them not to.
This feels a bit out of touch and passing the blame. Maintainability is important because it affects the company's bottom line. If it doesn't produce business value then you're making a bad decision in your project.
If there's pushback from management then it is the responsibility of the engineers to translate how maintainability translates into future improved throughput.
I get it that there's often dysfunction on software projects, but engineers need to advocate effectively too, so that non technical stakeholders are on the same page.
@@PlerbyMcFlerb
"Feel"????
Buddy, because you "feel", that's why you don't understand the fact.
If I, as a team leader, made bad decisions, then that is nobody's fault, but mine.
However, posting fake jobs(Which are plenty), lying to employees, this thing is real and employers do that all the time.
Keep in mind, employers lie to employees all the time and they do that by hiring an entire HR department to do so for them. This is not what I "feel" or "imagine", this thing is real out there.
I have witnessed this lying thing between both employers and employees day in and day out, I also see insane job posting without logical sense, such as "5 years of experience" for "junior developers", even more for senior developers, on a daily basis.
You see, blaming other or blaming yourselves, that s*** is easy. But, understanding clear whose faults it belongs to, is the hard part.
I don't deny the fact that developers also have mistakes and bad habits. But they are not the ones who started the whole thing. The employers do. If the higher ups are liars, then the bottom down will follow.
@@PlerbyMcFlerb Management is hiring profesionals to do their job, maybe don't ask professionals to explain everything they are doing and why they are doing it, because you hired them to do a job, let them do the bloody job