I'm C# developer and 90% of the time I'm working with C#... But in order to get a job, I need to know the stack of technologies that is about to be 1 page long. The funny thing is that resume sites advise me to reduce this list significantly. p.s. Your guitar skills are getting better. Well done.
One issue my team faces is initiatives to combat "boredom". As a result, devs recommend new technologies just to try and learn new things. There is a movement within our company to keep tech employees happy by letting them learn and try new things. Sure that seems great on paper. However, it becomes a tactical tornado situation. And code reviews just end up being people just approving things because they don't understand the new thing. After a while that new thing isn't shiny and the folks that championed it move on or turnover. Then the dev team is stuck with a spaghetti code situation. "Rework" then becomes common tech-debt that then gets kicked down the road since it is lower priority to the fires and customer demands. After a while, the grumbling starts and folks no longer enjoy working on that app anymore. Vicious cycle just continues. Of course, there is ZERO documentation and poor comments to make the situation worse. The answer is, oh ya, so and so knew how to do that, but now they are gone, so just figure it out...
Thanks for sharing this. It’s incredible how common this has become. I’d even go so far as to say developers are expecting their employer to let them introduce new technology to be satisfied with the job. Unfortunately, those same people often haven’t developed mastery with the base technologies they’re using before introducing more. I’m all for growing skills in our career, but it needs to be done sustainably for the purposes of the team building the product.
Lots of companies keep their base technologies really out of date, which just lends to this problem. Devs read a blog post about some cool new C# features, only to learn that they cannot use them with their 10 year old runtime 😑
@@tylerkropp4380 there is a difference between keeping .Net stack up to date (so building against newest .Net framework and c# version) and switching parts of stack every 2 years. Start with jquery, go to react, now they want vue....
This is so critical and never talked about, just argued in the sidelines I have been researching the minimal tooling in the last couple years Loving web components
Are you overwhelmed with too many technologies and tools to finish software? What are some of the challenges you've faced, and solutions you've come up with? ►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/ CHAPTER MARKERS 0:00 Introduction 1:07 1 THE DANGERS OF TECH STACK COMPLEXITY 1:12 1.1 Tool Overload 1:40 1.2 Decision Fatigue 2:03 1.3 Integration Challenges 2:34 1.4 Cost Implications 3:26 1.5 Diluted Focus 3:44 2 SIMPLIFYING YOUR TECH STACK 3:52 2.1 Prioritize Value 6:35 2.2 Embrace Versatile Tools 7:39 2.3 Standardize and Document 8:50 2.4 Seek Community Input 10:01 2.5 Regular Review and Upgrading 11:33 Episode Groove
Have to update constantly because of the ridiculous "CHURN" where the big library creators feel it's necessary to constantly make changes - BREAKING changes. Angular seems to be particularly susceptible to that.
Symptoms of complicated tech stacks: 1) The notes from meetings are just names of libraries with question marks. 2) There is at least one guy who, when given a problem, even something that's just an hour or a few of coding, will instead find some library that kind of does it and introduce another dependency. 3) The software itself has hundreds of dependencies, is resource hungry, slow and glitchy an no one on the project is smart enough to fix any of it.
Variation of #2 - feature already exists ( and works ) in another part of the program, but a cool library "is standard" and that guy uses the library, instead.
One other thing to take into consideration is the stability/backwards-compatibility of each part. For example, in Java/Rust, things (at least in the core) tend to be pretty much the same across versions, however in some JS libraries you have quite a lot of breaking changes, which comes with a cost
Good point. I’m not sure if the perceived instability of the JS ecosystem is due to truly less stable change management, or just a result of how much more active it is than some others.
Another perspective is that if you do use a new technology, write your code as a loosely coupled microservice. If it gets too unwieldly, or a key developer leaves, or requirements change, you can just scrap that microservice and reimplement it with different technologies. I see part of the pain of complex tech comes from people being too insistent on holding on to old code, instead of admitting it doesn't work well and replacing it.
Great video, Jayme. As a junior backend dev I've seen some challenges where the technology can hold the team back. About half of my team's products were written by other teams and inherited by us. They all use different libraries, design patterns, and a few are even functional while the rest are object oriented. While educational, this often hinders our efficiency. We're now focusing on standardizing our tech stack for all new work. I'm gaining confidence as a dev and actively contributing ideas for standards. I'll keep your advice in mind to hopefully avoid creating similar pain in the long term.
For my own projects, I just use the officially supported packages of the programming language and a few other very common packages and build the rest from there. It's usually not that hard to implement things from scratch, even complex things like a little AI framework. Take ownership of the problem domain.
I try to take into account the relatively high developer experience so as not to get dragged down by bad decisions in the stack. Unfortunately, it's one of those things that improves quality for programmers and doesn't keep an eye on the consumers of the final product. If the project is short enough maybe you can look the other way, but in the long term you have to manage this too. A bad development experience causes slowness in on boarding and daily development. I didn't know the concept until a few years ago.
I agree. The challenge is each developer has a different definition of what a good developer experience is. I don’t think I’ve ever worked on a project where there weren’t several valuable patterns added to a base technology to provide enhancement to the developer experience. Unfortunately, some of the projects that grew out of control with complexity used developer experience as the justification for each new library, pattern, or service - without looking at the other costs to adoption. I guess that’s why I’m advocating what I do here.
I agree reduce dependencies. Use a platform and frameworks that cover a high percentage the needs of the project and managed dependencies, where possible. I'm cautious about crowd sourcing solutions. People push solutions to problems you may not even have. It's easy to get into a Blog vs Blog debate. Look to the platform for a solution first and then an external dependency.
Where I work, we've hit that issue where making big changes (including technologies) isn't something management are that keen on given the time investment it needs. Technology choices tie in to architecture and that's more work and risk to change.
huh... not sure how I didn't come across your videos before, but have to say, good job 👍 thank you for the content at first wasn't sure about the guitar inserts, but they're growing on me ☺
Great video. I totally agree. I've tried to push simplicity on my current project but it's hard when there are people who seem to love building complex solutions. I would love to hear your thoughts on this whole microservices architecture debate. I often have the feeling that people seem to regard it as a holy grail and they split up their software for no justified reason. Just to wonder why everything is so hard to operate and maintain in the end.
Although I'm fully behind simplifying the tech stack, I wonder if the recent wave of massive layoffs we have seen in our industry is not augmenting substantially the burden in software developers who accumulate more functions.
If you don't do it yourself (simplifying the tech stack) sooner or later the company/ organizations will enforce it by defining standards. In the end it's too much know how to be sustained. You end up with lots of maintenance task keeping the integrations working.
Your videos and advice are awesome. Currently work in IT on Service Delivery side and looking to transition to applications. Finding it hard to find a learning path.
My biggest complaint is when managers push a new tool that no one on the team has no experience with. My previous manager pushed Git as the source control for legacy apps written in old versions of Visual Studio. I had used SVN with VS 2005, he wanted Git. The issue became that Git didn't hook into VS 2005 and wasn't really supported. What a waste of time.
Hey HSD, I do have a similar background, I am also a software dev and I also play guitar and I also grew up in a narcissist's family. It's really cool to see ya doing these kind of talk vids, I agree with most stuff you talk about and I am more than happy to learn new stuff as well. But my question, even though completely unrelated, is: have you got a channel where you do music?
Rust is great, but its ecosystem has the same pitfalls that this video describes. It also lacks anything resembling a batteries-included framework like Ruby on Rails, AFAIK. That isn't necessarily bad, but there's definitely some package mixing/matching involved when setting up a Rust stack. Also, the language itself is complex.
rust syntax is the definition of tool overload. like cpp people spend 5 hours trying to figure out the best way to do 1 line of code rather than moving on
@@michaelthompson7217 Yes and no. The Rust syntax is not the problem. The paranoia of the compiler is. It's like walking through a mine field - you have a clear vision of your destination (and the nice fluent-API-like feeling of the Rust world enhances that) but to get there you need to do some evasive maneuvers.
Do whatever works for you, of course. I think the reason this can sometimes be a problem, is I'll have a false confidence that my sense of something being easy to be understand is true for everyone else. Basically, when you use a popular package you are tapping into a collective agreement that something is suitable. It's also usually well-documented. Of course there are cases where the popular package is overkill. I'm OK with using something smaller as you say, but then I'm taking on responsibility for supporting it, teaching everyone how to use it, and maintaining it if the maintainers bail because it's too small. Basically it's a set of tradeoffs. I guess in my experience I come across more people that cherry pick unpopular packages and then make the codebase hard to work with because they don't know how to support it properly. So I'm definitely a little biased to be sure.
@@HealthyDev First of all, i believe everyone with experience is biased. I get paid to develop PHP based websites/web applications for about 10 years (+3 if the phase to get their counts). Since about 3.5 years i get paid to develop in Node (Typescript) but still get in contact on some legacy projects and in my spare time (maintaining libraries). Especially in the PHP world it felt like either you believe in Lavarel, Symfony or you where part of a small minority not believing in full stack frameworks. My development career started with Symfony. The more i learned about it and the more i learned about design, the more i was convinced, that full stack frameworks can never be the best solution for a sustainable project, no matter its popularity is. So its about choosing micro framework and a bunch of libraries to get the best results. Yes this decisions should be challenged from time to time and especially if bigger problems arise. Theoretically this could be done with full stack solutions as well, if they are modular, but people who prefer them also tend to prefere not to challenge them, therefor discussions about this topic can be extremely annoying. I wrote and still write libraries, cause the popular once weren't good enough (i do not accept mediocre solutions for critical parts of an application).
I suppose I’d have to be freaked out to make those. 😉 Plenty available already on RUclips from other people! My view is a bit more, let’s say, balanced.
Thing i do is only using stuff till it is really needed. Keep it simple, long as possible. Add dependencies nog before you use it. Ask questions to yourself like, can we do it without that library, how difficult is to do it yourself? Do you really need more a database? Or can it now be static at this moment. Dont think to much from a framework, think in a higher level what are you really building, and on the most simple way. Frameworks can be great, but dont build everything around that framework. And if a framework is too opinionated and everywhere needed, that is for me a red flag, because that makes future decisions more hard, and the process will be less Agile.
I've had experience of trying to simplify tech stack. Let's just say that I've simplified K8S monstrosity hosted on AWS EKS with manual Redis cluster management (deployed on K8S) and manual telemetry configuration to AWS Elastic Beanstalk and AWS Elasticache. For such a simple app it was reducing infrastructure complexity by large large amount (about 80% less complexity, bugs and no "stuck" k8s pods). I was rewarded by more stress, and cancel culture because k8s "gods" had have their own. Almost had full-blown panic attacks on that job due to management decisions, so I simply quit.
Yes, the same happened to me. I questioned the need to add k8s (and microservice architecture) to our miniscule project a few years ago. I instantly got berated by the kube-gods and painted as a non-team player for blasphemy. After the kube-gods had their fun and left they handed over a big bag of odorous excrement for the poor maintainers (including me) to deal with that was just damn overkill. Couple guys got burnouts trying to deal with it. I've left the job since but I still hear it has some serious issues just staying online. So basically: people who obsessed over service license agreements developed a solution so complex that it failed to fulfill those service license agreements. A cruel irony indeed hah. Really makes you think about the state of the industry. Please don't have fun with the expense of other people. Everybody is just trying to make a living here. If you feel bored about the domain you are working in don't try to fix your boredom by becoming a tool-oriented guy, find a more interesting domain to work in and pour your creative energy into solving problems of that business. Before you jump into technologies used by FAANG's to adress specific contextual problems they have try to get the basics right, you know, stuff like automated testing. Please keep in mind I'm not hating k8s here, it is a great piece of technology but it's overkill unless you work for a one of the top tier fortune 500 companies. You just don't have the problems it solves.
How about the supervisor relying on "Superstar" engineers to do virtually all the fundamental new work, relegating the rest of the engineers to bug fixes and tweaks? We have one of those and he uses the absolute latest-greatest-bleeding-edge stuff possible. One time three senior engineers were trying to decipher one of his ( in this case, buggy ) blocks of code and - couldn't. I reworked it, fixing the bug. That engineer then removed my code and replaced it with his [fancier] code. I could go on, and on, and on. Oh, and the idea that the more you can cram onto one line of code, the better it is. I - tried to give the manager a hint when I mentioned that long ago there were tongue-in-cheek contests where people would write single-line c programs. Sure, everything can go on one line - 'course that line is 36,000 characters long.....
Hi There! I am working from India, in a Service based IT outsourcing company and the developers have to work on a remote desktop which is painfully slow to work with. The latency is too damn high that even a mouse click or a key press would take 3 seconds to reflect. This is such a let down while working. Can you please pick this topic as well. "Working on a Remote Desktop from a far away country"
Hey there. I’m sorry to hear how frustrating that must be. Unfortunately I don’t think I have a video worth of advice for coping with that. I’ve had projects here in Austin with a few companies that required Remote Desktop access and it was always a barrier to efficient work. I try to work with clients that allow me to access their resources through authentication directly with their services whenever possible to avoid that.
I have been in contact with a few developers from Indian subcontractors of my company and I feel really sorry for them. The quality of IT equipment over there is a shame. It's not just "remote desktop is slow". The engineers get shitty gear to work with from the start, like 10 year old laptops. And then, for "high performance tasks", they have to log in into "remote desktop benches" which they have to book in advance. To find something like the cheapest Core-i7 with 4*2 cores with max. 16GB RAM, i.e. 4+ year old CPUs from times before COVID.
Over a long period of time I’ve learned that DRY, taken to extremes, can be a real problem. If you have to write more lines of code but it’s well documented, supported, and part of your stack already I usually lean that way. Creating new stuff for the sake of DRYness needs to save a lot of complexity to justify yet another pattern or concept.
@@HealthyDev - it's not just DRY. But I've seen that too. There needs to be someone in the room that speaks up and says "what are we actually gaining from this additional complexity?" But for me, the thing that's killing us is the million and one technologies that we have to know. From DEV OPS, to coding in multiple languages, to Cloud stacks, to testing frameworks. It feels sometimes like a tidal wave. And we move SOOOO slowly. But like I said, nobody cares.
@@strathoundagreed, the scope of understanding required of us as modern developers gets baffling. We all get there I suppose but I really have a lot of sympathy for people just starting out and trying to get their arms around it all.
the industry has gone mad with complexity. When I pitch things to keep it simple they never get adopted and people look at me like im crazy
Completely agree
So I'm not on my own in this then. The older I get I want fewer libraries, fewer layers of abstraction.
@@yetanotherbloke yeah, I think it does tend to be that way for people who have been in the industry longer, however they seem to be the minority.
People keep telling my they like TWCSS because they find it hard to learn CSS. I feel like I'm going crazy.
@@TravisHi_YT tailwind is modern bootstrap essentially. It actually simplifies things tbh.
I'm C# developer and 90% of the time I'm working with C#... But in order to get a job, I need to know the stack of technologies that is about to be 1 page long. The funny thing is that resume sites advise me to reduce this list significantly.
p.s. Your guitar skills are getting better. Well done.
Let's see when Jammy joins the "Canon Rock Covers" club ;-) .
One issue my team faces is initiatives to combat "boredom". As a result, devs recommend new technologies just to try and learn new things. There is a movement within our company to keep tech employees happy by letting them learn and try new things. Sure that seems great on paper. However, it becomes a tactical tornado situation. And code reviews just end up being people just approving things because they don't understand the new thing. After a while that new thing isn't shiny and the folks that championed it move on or turnover. Then the dev team is stuck with a spaghetti code situation. "Rework" then becomes common tech-debt that then gets kicked down the road since it is lower priority to the fires and customer demands. After a while, the grumbling starts and folks no longer enjoy working on that app anymore. Vicious cycle just continues. Of course, there is ZERO documentation and poor comments to make the situation worse. The answer is, oh ya, so and so knew how to do that, but now they are gone, so just figure it out...
Want to learn something new? Great! Spin up a side project.
Thanks for sharing this. It’s incredible how common this has become. I’d even go so far as to say developers are expecting their employer to let them introduce new technology to be satisfied with the job.
Unfortunately, those same people often haven’t developed mastery with the base technologies they’re using before introducing more. I’m all for growing skills in our career, but it needs to be done sustainably for the purposes of the team building the product.
@@HealthyDev 100% agreed.
Lots of companies keep their base technologies really out of date, which just lends to this problem. Devs read a blog post about some cool new C# features, only to learn that they cannot use them with their 10 year old runtime 😑
@@tylerkropp4380 there is a difference between keeping .Net stack up to date (so building against newest .Net framework and c# version) and switching parts of stack every 2 years. Start with jquery, go to react, now they want vue....
This is so critical and never talked about, just argued in the sidelines
I have been researching the minimal tooling in the last couple years
Loving web components
Are you overwhelmed with too many technologies and tools to finish software? What are some of the challenges you've faced, and solutions you've come up with?
►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/
CHAPTER MARKERS
0:00 Introduction
1:07 1 THE DANGERS OF TECH STACK COMPLEXITY
1:12 1.1 Tool Overload
1:40 1.2 Decision Fatigue
2:03 1.3 Integration Challenges
2:34 1.4 Cost Implications
3:26 1.5 Diluted Focus
3:44 2 SIMPLIFYING YOUR TECH STACK
3:52 2.1 Prioritize Value
6:35 2.2 Embrace Versatile Tools
7:39 2.3 Standardize and Document
8:50 2.4 Seek Community Input
10:01 2.5 Regular Review and Upgrading
11:33 Episode Groove
Keeping a pre-defined schedule to update dependencies is something I started doing at my last job.
Have to update constantly because of the ridiculous "CHURN" where the big library creators feel it's necessary to constantly make changes - BREAKING changes. Angular seems to be particularly susceptible to that.
Symptoms of complicated tech stacks:
1) The notes from meetings are just names of libraries with question marks.
2) There is at least one guy who, when given a problem, even something that's just an hour or a few of coding, will instead find some library that kind of does it and introduce another dependency.
3) The software itself has hundreds of dependencies, is resource hungry, slow and glitchy an no one on the project is smart enough to fix any of it.
Variation of #2 - feature already exists ( and works ) in another part of the program, but a cool library "is standard" and that guy uses the library, instead.
One other thing to take into consideration is the stability/backwards-compatibility of each part. For example, in Java/Rust, things (at least in the core) tend to be pretty much the same across versions, however in some JS libraries you have quite a lot of breaking changes, which comes with a cost
Good point. I’m not sure if the perceived instability of the JS ecosystem is due to truly less stable change management, or just a result of how much more active it is than some others.
What do you mean, simplify? What could be simpler than `npm install the-entire-internet`?
Haha! 🤣
"It just works!"
Another perspective is that if you do use a new technology, write your code as a loosely coupled microservice. If it gets too unwieldly, or a key developer leaves, or requirements change, you can just scrap that microservice and reimplement it with different technologies.
I see part of the pain of complex tech comes from people being too insistent on holding on to old code, instead of admitting it doesn't work well and replacing it.
I used to love finding new libraries and dependencies; now, I just want to learn and use Django and Htmx. :)
Great video, Jayme. As a junior backend dev I've seen some challenges where the technology can hold the team back. About half of my team's products were written by other teams and inherited by us. They all use different libraries, design patterns, and a few are even functional while the rest are object oriented. While educational, this often hinders our efficiency. We're now focusing on standardizing our tech stack for all new work. I'm gaining confidence as a dev and actively contributing ideas for standards. I'll keep your advice in mind to hopefully avoid creating similar pain in the long term.
For my own projects, I just use the officially supported packages of the programming language and a few other very common packages and build the rest from there. It's usually not that hard to implement things from scratch, even complex things like a little AI framework. Take ownership of the problem domain.
I try to take into account the relatively high developer experience so as not to get dragged down by bad decisions in the stack. Unfortunately, it's one of those things that improves quality for programmers and doesn't keep an eye on the consumers of the final product.
If the project is short enough maybe you can look the other way, but in the long term you have to manage this too. A bad development experience causes slowness in on boarding and daily development. I didn't know the concept until a few years ago.
I agree. The challenge is each developer has a different definition of what a good developer experience is.
I don’t think I’ve ever worked on a project where there weren’t several valuable patterns added to a base technology to provide enhancement to the developer experience.
Unfortunately, some of the projects that grew out of control with complexity used developer experience as the justification for each new library, pattern, or service - without looking at the other costs to adoption. I guess that’s why I’m advocating what I do here.
I agree reduce dependencies. Use a platform and frameworks that cover a high percentage the needs of the project and managed dependencies, where possible. I'm cautious about crowd sourcing solutions. People push solutions to problems you may not even have. It's easy to get into a Blog vs Blog debate. Look to the platform for a solution first and then an external dependency.
Where I work, we've hit that issue where making big changes (including technologies) isn't something management are that keen on given the time investment it needs. Technology choices tie in to architecture and that's more work and risk to change.
Thanks for the tips!! And btw, you're really getting better at that guitar !!
huh... not sure how I didn't come across your videos before, but have to say, good job 👍 thank you for the content
at first wasn't sure about the guitar inserts, but they're growing on me ☺
Great video. I totally agree. I've tried to push simplicity on my current project but it's hard when there are people who seem to love building complex solutions.
I would love to hear your thoughts on this whole microservices architecture debate. I often have the feeling that people seem to regard it as a holy grail and they split up their software for no justified reason. Just to wonder why everything is so hard to operate and maintain in the end.
This is helpful for being proactive in avoiding the pitfalls of Resume-Driven Development. Thanks!
Nice song you've chosen to play. Never heard it before. What's the name of it? Who wrote it? Thanks!
Oh it’s a song I wrote about my wife and I.
@@HealthyDev I find it soothing... thank you for playing it.
@@johnnyblue4799 nice! Thanks :)
Although I'm fully behind simplifying the tech stack, I wonder if the recent wave of massive layoffs we have seen in our industry is not augmenting substantially the burden in software developers who accumulate more functions.
If you don't do it yourself (simplifying the tech stack) sooner or later the company/ organizations will enforce it by defining standards. In the end it's too much know how to be sustained. You end up with lots of maintenance task keeping the integrations working.
Your videos and advice are awesome. Currently work in IT on Service Delivery side and looking to transition to applications. Finding it hard to find a learning path.
My biggest complaint is when managers push a new tool that no one on the team has no experience with. My previous manager pushed Git as the source control for legacy apps written in old versions of Visual Studio. I had used SVN with VS 2005, he wanted Git. The issue became that Git didn't hook into VS 2005 and wasn't really supported. What a waste of time.
Hey HSD, I do have a similar background, I am also a software dev and I also play guitar and I also grew up in a narcissist's family. It's really cool to see ya doing these kind of talk vids, I agree with most stuff you talk about and I am more than happy to learn new stuff as well.
But my question, even though completely unrelated, is: have you got a channel where you do music?
What happens if you don't update dependencies?
True, just pick Rust and finish.
not the easiest choice for web development ;)
There are many valuable languages and tools, but they should be minimized for each project itself
Rust is great, but its ecosystem has the same pitfalls that this video describes. It also lacks anything resembling a batteries-included framework like Ruby on Rails, AFAIK. That isn't necessarily bad, but there's definitely some package mixing/matching involved when setting up a Rust stack. Also, the language itself is complex.
rust syntax is the definition of tool overload. like cpp people spend 5 hours trying to figure out the best way to do 1 line of code rather than moving on
@@michaelthompson7217 Yes and no. The Rust syntax is not the problem. The paranoia of the compiler is. It's like walking through a mine field - you have a clear vision of your destination (and the nice fluent-API-like feeling of the Rust world enhances that) but to get there you need to do some evasive maneuvers.
I would say pick JavaScript and build everything from desktop to mobile until web solutions
This should go for not only software development but for IT department management organization and tools. Simplest is best.
As long as a package is small and easy to understand, i would choose it over popular packages at anyday if the code and api is better.
Do whatever works for you, of course. I think the reason this can sometimes be a problem, is I'll have a false confidence that my sense of something being easy to be understand is true for everyone else. Basically, when you use a popular package you are tapping into a collective agreement that something is suitable. It's also usually well-documented.
Of course there are cases where the popular package is overkill. I'm OK with using something smaller as you say, but then I'm taking on responsibility for supporting it, teaching everyone how to use it, and maintaining it if the maintainers bail because it's too small. Basically it's a set of tradeoffs. I guess in my experience I come across more people that cherry pick unpopular packages and then make the codebase hard to work with because they don't know how to support it properly. So I'm definitely a little biased to be sure.
@@HealthyDev First of all, i believe everyone with experience is biased. I get paid to develop PHP based websites/web applications for about 10 years (+3 if the phase to get their counts). Since about 3.5 years i get paid to develop in Node (Typescript) but still get in contact on some legacy projects and in my spare time (maintaining libraries). Especially in the PHP world it felt like either you believe in Lavarel, Symfony or you where part of a small minority not believing in full stack frameworks. My development career started with Symfony. The more i learned about it and the more i learned about design, the more i was convinced, that full stack frameworks can never be the best solution for a sustainable project, no matter its popularity is. So its about choosing micro framework and a bunch of libraries to get the best results. Yes this decisions should be challenged from time to time and especially if bigger problems arise. Theoretically this could be done with full stack solutions as well, if they are modular, but people who prefer them also tend to prefere not to challenge them, therefor discussions about this topic can be extremely annoying. I wrote and still write libraries, cause the popular once weren't good enough (i do not accept mediocre solutions for critical parts of an application).
When do we get the videos about freakout over robots taking all our coding jobs? Great video by the way.
I suppose I’d have to be freaked out to make those. 😉 Plenty available already on RUclips from other people! My view is a bit more, let’s say, balanced.
@@HealthyDev haha well said. Love, love your channel man.
Thing i do is only using stuff till it is really needed. Keep it simple, long as possible. Add dependencies nog before you use it.
Ask questions to yourself like, can we do it without that library, how difficult is to do it yourself? Do you really need more a database? Or can it now be static at this moment.
Dont think to much from a framework, think in a higher level what are you really building, and on the most simple way.
Frameworks can be great, but dont build everything around that framework.
And if a framework is too opinionated and everywhere needed, that is for me a red flag, because that makes future decisions more hard, and the process will be less Agile.
Are the songs you play your own compositions?
I've had experience of trying to simplify tech stack.
Let's just say that I've simplified K8S monstrosity hosted on AWS EKS with manual Redis cluster management (deployed on K8S) and manual telemetry configuration to AWS Elastic Beanstalk and AWS Elasticache.
For such a simple app it was reducing infrastructure complexity by large large amount (about 80% less complexity, bugs and no "stuck" k8s pods).
I was rewarded by more stress, and cancel culture because k8s "gods" had have their own. Almost had full-blown panic attacks on that job due to management decisions, so I simply quit.
Yes, the same happened to me. I questioned the need to add k8s (and microservice architecture) to our miniscule project a few years ago. I instantly got berated by the kube-gods and painted as a non-team player for blasphemy. After the kube-gods had their fun and left they handed over a big bag of odorous excrement for the poor maintainers (including me) to deal with that was just damn overkill. Couple guys got burnouts trying to deal with it. I've left the job since but I still hear it has some serious issues just staying online. So basically: people who obsessed over service license agreements developed a solution so complex that it failed to fulfill those service license agreements. A cruel irony indeed hah. Really makes you think about the state of the industry.
Please don't have fun with the expense of other people. Everybody is just trying to make a living here. If you feel bored about the domain you are working in don't try to fix your boredom by becoming a tool-oriented guy, find a more interesting domain to work in and pour your creative energy into solving problems of that business. Before you jump into technologies used by FAANG's to adress specific contextual problems they have try to get the basics right, you know, stuff like automated testing.
Please keep in mind I'm not hating k8s here, it is a great piece of technology but it's overkill unless you work for a one of the top tier fortune 500 companies. You just don't have the problems it solves.
How about the supervisor relying on "Superstar" engineers to do virtually all the fundamental new work, relegating the rest of the engineers to bug fixes and tweaks? We have one of those and he uses the absolute latest-greatest-bleeding-edge stuff possible. One time three senior engineers were trying to decipher one of his ( in this case, buggy ) blocks of code and - couldn't. I reworked it, fixing the bug. That engineer then removed my code and replaced it with his [fancier] code. I could go on, and on, and on.
Oh, and the idea that the more you can cram onto one line of code, the better it is. I - tried to give the manager a hint when I mentioned that long ago there were tongue-in-cheek contests where people would write single-line c programs. Sure, everything can go on one line - 'course that line is 36,000 characters long.....
excelent music
Hi There! I am working from India, in a Service based IT outsourcing company and the developers have to work on a remote desktop which is painfully slow to work with. The latency is too damn high that even a mouse click or a key press would take 3 seconds to reflect. This is such a let down while working. Can you please pick this topic as well. "Working on a Remote Desktop from a far away country"
Hey there. I’m sorry to hear how frustrating that must be. Unfortunately I don’t think I have a video worth of advice for coping with that. I’ve had projects here in Austin with a few companies that required Remote Desktop access and it was always a barrier to efficient work. I try to work with clients that allow me to access their resources through authentication directly with their services whenever possible to avoid that.
I have been in contact with a few developers from Indian subcontractors of my company and I feel really sorry for them. The quality of IT equipment over there is a shame. It's not just "remote desktop is slow". The engineers get shitty gear to work with from the start, like 10 year old laptops. And then, for "high performance tasks", they have to log in into "remote desktop benches" which they have to book in advance. To find something like the cheapest Core-i7 with 4*2 cores with max. 16GB RAM, i.e. 4+ year old CPUs from times before COVID.
So, NOT React?
"I'm sure AWS will solve this"
God bless u
Yes, cognitive overload is a real thing. And it paralyzes teams. But nobody seems to care about productivity anymore.
Over a long period of time I’ve learned that DRY, taken to extremes, can be a real problem. If you have to write more lines of code but it’s well documented, supported, and part of your stack already I usually lean that way. Creating new stuff for the sake of DRYness needs to save a lot of complexity to justify yet another pattern or concept.
@@HealthyDev - it's not just DRY. But I've seen that too. There needs to be someone in the room that speaks up and says "what are we actually gaining from this additional complexity?" But for me, the thing that's killing us is the million and one technologies that we have to know. From DEV OPS, to coding in multiple languages, to Cloud stacks, to testing frameworks. It feels sometimes like a tidal wave. And we move SOOOO slowly. But like I said, nobody cares.
@@strathoundagreed, the scope of understanding required of us as modern developers gets baffling. We all get there I suppose but I really have a lot of sympathy for people just starting out and trying to get their arms around it all.
ha-ha
classic
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.