exactly this career is exhausting because its not science its like philosophy , there is always an argument against and argument with , the optimal path is not clear , one must have power in team in order to work , knowledge or experience alone is not enough , because egos will be fighting all the time
most of what you are pointing out is accurate AF, but the source of these "changes" come typically from the parasitic upper management class that need to justify their existence in the organization
The tone of this video is different. I hope you’re doing ok Hussein. Just want to let you know that your content has been both one of my primary resources and an inspiration for the first 5-6 years of my career.
There were also MANY cuts in this video as opposed to what's normally a single continuous take. It stands to reason that he cut out a lot of particularly negative stuff. He also looks absolutely exhausted - his eyes, in particular, are lacking his normal animation and passion. I hope he'll be able to get some rest, and perhaps new projects to focus his passion on!
I started "Understanding the reason behind everything" mentality a month ago after knowing you! Literally the most important skill any software developer should acquire.
@@magdynasr6639 Sometime I want to dig deep into a problem. But due to time constraints I would have to take a pass and just solve the problem. How do you find time to solve the problem as well as dig deep into it?
@@bonniesimon14 That's a very tough question! depends on your situation, are a student or do you work? the answer to this question differs a lot. another one, what is your level, are you beginner, junior or even senior? based on these question you start to manage your time so that you make the most use of your time.. for me I am focusing on the knowledge as I am a junior sw engineer so I must gain knowledge as much as possible so that I grow healthy in this field. SO back to your question when to dig deep and when to skip? the answer is: It 's always better to dig deep into a topic or a problem BUT if you have to finish a certain task for the sake of a deadline so just solve the problem but don't make it a habit! NEVER make this a habit I hope my answer helps!
I've been thinking a lot of similar thoughts recently. I think the field is just in a weird transitional phase. We very rapidly went from experts that could hold nearly all the abstractions in our heads, to now only holding a fraction of them. From having very predictable execution environments where we have confidence in our programs, to having to wrap all of our stuff up in protective containers to make sure they survive out there in the wild. Back in the day, I think the ego was a very good thing. It allowed people who "knew their stuff" so well they could just work with their gut and move extremely quickly. But as we move into a more complex, generalized AI-powered online world, we're rapidly losing our ability to understand the entirety of the field. We still need some room to take risks and innovate, but could definitely use some more sophisticated methods and a more mature culture beyond "oh they're super smart, just let them go at it".
Agree, have personally experienced the scenario when as a junior engineer proposing a new approach and design which was discarded without understanding the impact and the performance gains, totally relate with EGO a senior has, which is generally combined with ownership and superiority.
Just further feeds into the culture. You gotta embody the ego-centric-midset in order to get the job, then you embody it once you actually do the work :/
@@Spookyhoobster in sort you have to say yes in their yes rather than showing different perspective. Because as you said they don't want somebody to know more atleast in interview.Not everybody is like that but most of out there. Correct me If I am wrong. 🙌
I think everything boils down to "REQUIREMENT". If optimization is not a requirement, a developer might write the simplest working code and call it a day😅. If crappy working code is "good enough", no amount of optimization proposed will see the daylight of production. This battle of propose -> convince -> achieve for a "REQUIREMENT" to become "FULFILLED REQUIREMENT" is truly a hard one with lot of gray areas and for all the people who are battling these battles deserve my true respect and honour.
It's not always ego. There's many reasons why a good idea might not be implemented. Time, resource, risk, roadmap, product lifetime etc etc If your idea is good and your tech lead says "Good idea but we're not doing it right now because X", that doesn't mean he has an ego about it. On the other hand, if you have a good idea and he shoots it down without explaining why... that's a problem.
As the developer of a 2D game I have, many times, re-written my code that was perfectly working before just because I didn't like how the files were structured and/or wanted it to use this new paradigm or class that I made, rather than fixing one bug I rename 1359318509135 symbols in Vscode and never get any actual work done. These type of re-engineering has to be avoided at all costs, just get the stuff to work, and work well, and go about refactoring a little bit at a time rather than a sweeping action.
refactoring is a great way to get better at coding in general. you have to do what you're talking about to hone your preferred style. you won't get to writing great code by doing one-and-dones. but once you do write great and clean code then that will be your starting point for future projects. i have seen people do one-and-dones for years without ever understanding how to write great code or what the difference is.
Yep, I'm frequently guilty of premature optimization and I think a lot, or maybe most developers, scientists, technical experts, etc. are a bit obsessive and while it's a strength at times, it can also be a weakness unchecked...
Instinct tells you everything needs refactoring, but that should always go through a logic check. "If I refactor how much value do we get" "Does this value outweigh another task I could be doing?" and so on. Often you'll realise that refactoring isn't as important as your instinct makes it seem. Especially for features that already work fine and aren't causing issues.
We had a folder structure to manage and store various projects that works fine our new boss came a and changed it just for the sake of proving herself then the whole server is fucked up, I gave up trying to clean it of fixing things
I appreciate this video. I complain vehemently about these problems in modern software in the frame of mind of "them" - but I am one of them. This video is digging into the core of us-them.
The majority of devs get lost in their code and forget the end goal is just a happy user. Don't get me started on "developer experience", imagine a plumber saying "plumbing experience."
Well they do. Every day. They need working tools and if they are not working, something that gets the job done better, faster and reliably are taken into use. If a plumber would forget that the end goal is to have a working pipe they'd tear up a wall just to change the color of the perfectly working plumbing. I think that's more the case here. But you do need to test different pipes and tools constantly to know if any improvement can be done. So when do you test it? While working real job that generates revenue or invest in actual R&D type of activities that "only have a cost to run"?
I disagree developer experience is really important thing. Just like plumbing you need a certain setting to make your work properly. So developers also need certain setting to work efficiently. For example if your project is hard to setup locally that will impact negatively on dev productivity because they can't easily onboard. I think this kind of "developer experience" is important. You can't build a good product if you can't work on the product effectively.
@@jonijarvinen7833 nice thinking, I'm also sick and tired of people treating their projects as personal science fair experiments. Forceful pushing of things like distributed architectures for somebodys personal pleasure or marketing benefit completely ignores the tradeoffs. It's 'great' fun trying to salvage these trainwrecks as a maintenance dude.
exactly this career is exhausting because its not science its like philosophy , there is always an argument against and argument with , the optimal path is not clear , one must have power in team in order to work , knowledge or experience alone is not enough , because egos will be fighting all the time
it's always the same story in any field, the industry just kills the Vibe, even this AI thing is something wanted by industries not even end Users, so good job humanity, we are going straight to the wall .
There's a lack of expertise today in software engineering making expert decisions. The barrier to entry has gotten so low and the latest tools/frameworks/techniques are rotating every year the software is suffering across the board
We used to call that "Management By Buzzword". I worked for a big company with lots of higher up IT people (VPs, Directors, etc.) and they would talk. Our Director was NOT a tech person and had no way of evaluating one path over another. So they defaulted to talking to all the other "smarter" Directors. If one director was doing something and we weren't, we were suddenly supposed to drop everything and implement their new thing or have a damned good reason why we're NOT going to do that thing. From an individual contributor perspective, it was like being a pinball in a pinball machine! But this attitude is not limited to non-techies. You're right that it's often based on ego without any additional supporting evidence or knowledge. We once implemented a solution that was easy but not optimal because we had to technical knowhow to make it happen coupled with a VERY small window to get it done and HUGE downside risks for missing our deadline. After it was deployed and successful, we brought others onto the team. Many of them immediately criticized the solution and were VERY accusatory and condescending towards us that were in the trenches at the time. Saying things like "You took on Technical Debt when you didn't need to" and "You deployed a solution that is not good, nor is it sound, nor is it robust nor is it.......well you get the idea. Any insult they could think of was hurled at us. BUT it was working and working well with VERY FEW issues. After a year, one of those people came to me and apologized and actually said that they were wrong for being so critical and that they actually liked our solution. It provided various features that we were now utilizing to actually broaden the services we were providing - services which would not be possible to provide with a different solution. This is why I try NOT to criticize other people's work even when I disagree with their approach. They have reasons for doing what they've done and sometimes those reasons are significant and should NOT be dismissed quickly.
Hi Hussein It seems like you’ve experienced some "we have to add this new unnecessary feature" BS at work this week. I can feel your anger permeating through the screen 😂.
I've seen this mostly with the new CXOs and PMs. They just know what should work based on their prior exp and they can't take anything new being done as an input. So they make engineers do things like this most often. And, I am sure the splash screen idea was also from these guys instead of 1 of the engineers as we know it's a 5 minute task to add a splash screen and doesn't bring any difference in our lives.
Been following you for nearly 3 years now. But In this video, you seem really low and down. You are one of the reasons that motivated me the similar times and have been a continuous inspiration since. You will bounce back 🙂again.
What I don't enjoy in OSS is the people in it. I come from a specific community that has this mentality - "your suggestion means nothing if you don't have PR with it". Even if the suggestion is as trivial as no code is needed to understand what someone is trying to point out. Instead, if you are a top guy/gal in that community, your PR can be as junior like as it can be and it will be merged, no questions asked. I have noticed that whenever someone challenges that mindset, they get completely ignored and labeled as "hater".
@@skyhappy not only that, but they think that if you pay/support their software, you are no better than someone who doesn't. Like, you don't even deserve priority issue fixes even if you pay them. Then it's for open argument of - where does my money go? Does it go to your lunch and therefore, even if I buy you lunch, I cannot even get better support with your product? It was quite ironic to hear backlash on this, when the donation I gave unlocked part of their docs, lool
Altium studio had this happen. Went from old-looking but fast to modern-looking but sluggish. Fortunately I had hit the point of my degree program I was barely using it by that time.
I was recently hired in a company as a software engineer ... I noticed the senior engineers are very defensive against any new idea I share with them At the same time I get worried if I'm adding those new ideas because of my ego or not I think the best solution is to talk and argue over things and discuss what we value as a company or a team Working from defining value in a product is very helpful in the beginning
Usually (let's say 95% of the cases) the reason why senior developers are change adverse is because their experience allows them to ponderate the pros and cons of such changes. Let's take one example: You watch this amazing tech-talk about this revolutionary database Y that is so much better than database X, which your current company is using. On the next day, you go to work and tell your senior coworkers about this amazing new technology and how good it would be to adopt it. Sounds familiar? Think about it for a second. You just heard about this new database yesterday, and in the best case you also spent a few days researching about it before suggesting it to your senior co-workers. Now, let's say that on average, a new database comes out every 3-6 months. Can you estimate how many new databases have your senior co-workers seen come and go during their career? Let alone how many times they have seen it, they were juniors at some point in the past and they also had these "amazing" ideas that they got from reading a book or watching a tech-talk. The thing is that experience not only gives you a better sense for telling between what's good and what isn't. Experience also gives you wonderful lessons in the form of pain: Do you know how painful it is to switch from one database technology to another? If you are a junior, you probably don't. But your seniors probably do. This is a super-simplificated example, but I hope it helps you to better understand why usually seniors are change adverse.
@moy2010 Your attitude is exactly the type of ego this video is about. You went off on this person assuming their ideas are not worthwhile to even be had, let alone shared. You don't know them or how creative they are. All of your examples may reflect reality and you may have good points but your attitude and condescending tone is a manifesration of the same ego Hessein discusses in this video could stifle future communucation and hurt the organization.
“Ego” can sometimes boils down to feeling like you have to do something or prove something to keep your job. You then start coming up with useless features and criticisms (or dismissal of legitimate criticism).
This is a perfect explanation for MS Windows. Endless updates, long boot times, just like automobiles being updated and tweaked every year… it stirs the market and increases demand.
In the web mostly it is because of the new approach to development for instance using the single-page application approach. This approach makes the web application inefficient by making load time longer. I believe the good old HTML is and will be the best approach to developing web apps instead of using Apis
i miss those times where there were some constrains, current day devs wont care about, for example a simple notes app that is around 300mb, just because of the frameworks
Personally, I love seeing junior devs or those without as much experience come up with some great idea and it works. I encourage that all the time at my place of work. I think the fear of being out-shined and being considered less of an asset is the concern one would feel in that scenario. Collective success is important.
I feel exactly like the guy coming from outside with fresh ideas. But I'm also a senior developer, I know the pains in the field. I see the barrier of "let's use what we're used to" way too clearly - because I've been there in the same position - that's where I came from. I almost always have to abdicate of my own ideas to someone else just because this guy is there before me and I don't want to be the problem. But it's frustrating, I feel like in a prison having to accept that actually solving the problem is not that important for the company. So in the end I just let it go, and try to do my best in my own things - which is what really matters.
I find it funny that everyone in the comments talks about OTHER people, but don't introspect. I for example have noticed myself getting defensive without "real" objective reason about some parts of code I've written, I try to work at it but it isn't always easy to completely forgo the ego.
It used to be that IT was about CS, math and engineering. It was about red eyes and sci-fi. Then Eternal September happened. BOFH is a perfect example of what followed. And soon after money started flowing and hype began. It seemed like you could quickly write a couple HTML pages and become a billionaire! Or at least feel slightly better off financially in this modern unequal world. Everywhere you looked since "The social network"'s release in 2010, there's been this HYPE. Tons of people who otherwise wouldn't've joined IT, decided to jump in and have their piece of the pie, be it stable income, big money, fame or just FOMO. And how do you get promoted as an engineer? You add "rewrote from scratch", "implemented a pipeline" etc. to your CV. How do you get promoted as a manager? You add reports, each of which wants to be promoted as an engineer. The industry of mathematicians and engineers has become infected with HUSTLE, with people who need to prove themselves, to join or create a startup, to become a VC. A similar situation, but even worse, is taking place in AI. It used to be a quaint field, with career-seekers avoiding it like a plague, until money started flowing in, and suddenly the same people who before would never have allowed themselves to be seen anywhere near "these naive AI lunatics" are memorizing like crazy what cross-correlation is.
reqlly good one…i agree with this and nicely articulated. adding few more…sometimes management puts pressure on the technical leaders bring in new tech …sometimes couple of issues in an app and people form opinion about technology being flaky but where as the problems are in the way code is written which can be fixed easily.
Anything you said in this video screams Discord to me lmao. Though I do hope you are doing alright Hussein, you seem like you've been through a lot lately.
Not sure how you're doing Hussein but you sound tired in this video, please take your time to take a break if you need it, I hope you are doing well You are such an inspiration and we really appreciate your hard work to teach hard topics with such amazing detail and passion, but some times you have to give yourself some time to relax
It seems to me that ego is a bit of a pointless barrier and pain in the ass even for the person themselves. It makes you tend towards staying in your comfort zone and never learn anything new. The fact of the matter is things take effort to learn to a deep level and someone with a massive ego never wants to admit to themselves that they don't understand something right away. In the end they lock themselves into only understanding topics superficially
Sometimes these are A/B tests 😂 maybe the new UI is helping convert more free users to paying users. I personally hate to see changes in UI to which I am super acquainted to.
A/B testing with your users without considering their experience is repulsive to me. It's just like your goal in your comment, > "helping convert more free users to paying users". If your goal is only that, you'll be losing more users.
Can you please put the members only playlist in a youtube direct link instead of shortening url? It doesn't open in RUclips app. (I'm a member with other account)
Love all of your content Hussein. To raise the morale a bit with a joke, I think this goes to all jobs involve doing /creating things. Didn't ever happen to you for a plumber or electrician to came to your house and say "ooh, who did this? Oh my goodness this is all wrong and needs to be redone". And because you don't have so much expertise, you freak out. Hey I don't want my house to be set on fire or whatever. Same here. It happen to me countless times to be put to the wall only by asking one simple question: "Do we need this?" Do we need to go to the cloud? Do we need to change the database? Do we need serverless? Do we really need to REWRITE from scratch every time? To name just a few. To ego I'd add boredom. On my side, most of the times I've felt like people were straight up bored. We want to leave something behind and this is why, I think, we do this push to change everything, something.
This is why you should go down the DevOps engineer route aka. the dark side where as long as you automate stuff you'll be considered a hard worker (my insiders heard rumors and leaks about automating your automation so you can slack off without being caught at work but shhh don't tell anyone)
They are just pumping any software with infinite numbers of features which comes in cost of performance, usability, glitches and keep doing it for the sake to keep rolling the ball
I think software engineering field lacks educated people that know how to think, analyse, assess. It's not only about writing code or knowing some framework - being a good craftsman. As in any other field, you need to be able to see the problem, state it clearly, evaluate risks/benefits of solving it or leaving as it is and making a decision. It involves calculations, not only your gut feeling...
Two years ago I was a web developer. Now I'm programming chips and linux kernel tinkerer at work. What I want to tell you is web dev realm is so crowded and too many people who still in "mount of stupid" of dunning-krugger graph. I feel like the more high level programming developer, more ego evolved there. That's- just my intuition, let me know if I'm wrong
You didn’t contradict yourself because you said at the beginning “It’s one thing when the app works fine and someone comes in wanting to change everything”. Also I’d recommend reading The Scout Mindset by Julia Galef. It talks about this problem on a broader basis. She calls this type of thinking the “soldier mindset” and it plagues more than just software engineers.
Duolingo added a 5 second splash screen if you have a Duolingo premium subscription. So they chose to make the experience worse for paying customers, which is beyond my understanding
It drives me crazy when something so simple has to be 200 MB in size. I remember there used to be pride in the old days getting your application down in size and efficient but today it seems like absolutely no effort is put into making applications slim and efficient.
Hey, Hussein! Thx for the video! I think you are really touching an important issue with software development when talking about a developer's ego. Regarding this, what would you suggest to do to mitigate it? A better hiring process? A better process for building teams? Or perhaps a policy regarding engineering decisions?
I think you answered your own question. A few simple tweaks in the hiring process, team building process and engineering decisions might do it. Great question btw!
They say brand taste and meaning to the brand or whatever the webapp is about , do makes sense sometime in frontend , not always yeah that's definitely true
Instagram in a nutshell. Every week there is a restructuring of the UI, and not for the better. They keep removing useful features (I miss sharing a comment on a post to a chat), and keep adding crap features no one asked for.
IMHO it's often more complicated. What if you can't judge the benefits of an improvement beforehand? What if the majority of the team is against a good change? Would you make their egos unhappy to make justice for just one other developer? Recently I joined a team that I'm extremely out of tune with. We disagree in most cases. Are they egotistic? Not clearly. Superficially they are what you'd call an open and empathetic developer. At the same time, I feel constantly micromanaged and programmer-splained. It took me a while to figure out where's the problem and why it's in 100% on their side 😁 I'm half joking. In the end, I decided we're irreconcilable. We just don't fit. The moral of the story is: know what coding style and practices you are willing to accept and ask about them during your job interview.
You have to update the code - otherwise, the code will become stale. The team must be current in their codebase - or no one will remember how to work with it. Libs and technologies involved in your project are updating, and getting old bugs and vulnerabilities fixed - so you have to update your project too, adding new features by the way. This lead to increased complexity of the soft, and often to slacker performance.
I think also with the current job market has made it worse. Everyone has built bigger egos trying to prove that they are the best amongst a competitive pool of candidates.
Seen so many bad codebases in past decade, problem with modern day workflow is everyone wants to jump in cutting edge tech without evaluating pros and cons. They often forget that individual teams have their strengths and weaknesses. Good softwares are built on top of their skillset and expertise. Proper implementation and execution weighs more than getting out a product with buggy and half baked implementation as alot of those resources would be struggling with new language or stack. What I've found is, older softwares tend to be more stable in nature from begining because alot of them were not agile and followed software engineering practices that made these impmentationa more reliable and resilient towards unknown factors as those things were evaluated at very early stages of development. Modern day workflow is quite opposite and in the name of growth, innivation, it is going to cost more in terms of tech debt and bad codebase that newer maintainers will inherit or probably will be scraping in name of new implementation. Like it or not, unless you are a developer, software engineer, architect or someone building software, no one else in chain give a dime about how it's going to be impmented. Whuch makes it harder to take good decisions based on long term outcome. Often engineers and tech people have to convience them to make a sane decision which is in between and never good enough to throw out old garbage. Yesterday's experience : Instagram forgets to add save button in bio edit screen. "Yes we have automated builds but no good QA so you get app pushed on app stores without much oversight!" - why? Because all big tech love automation that they forget basic engineering practices. There are plenty of such examples. That's the reality..!
I’d just add that even old software is not gold. It just had less going on. It was simple like frying an egg. Modern software is like getting egg whites from a carton, then putting it in some machine, that then turns it into a 5-star gourmet omelette. All you wanted was a fried egg but you got something different with all of the headache of maintaining the magic machine and paying for the cartons. Abstraction and task offloading are both blessings and a curse. If the machine isn’t working, you have to troubleshoot that on top of your own stuff. Old school software was easier because you knew what you wanted from the get go, then planned to attain that. Whereas modern is like: you might want an egg, or an omelette, or a cake. It has to handle all these cases cause we don’t know what you want and neither do you.
I think you overlook an important aspect here. Most software developers do not actually develop software, they develop modules. They/We are very far from users and their needs. The best software usually started with an individual or a group who developed a solution for their problem. They had both the purpose and the means and that's why their products are good. We invented the term "product owner" for the role in a software project that creates that connection between the actual users and the product. Since we adopted this terminology, I did not see a single person who filled this role well. Businesses apparently do not really value this function. You can see that at Apple. Shortly after Steve Jobs left the company, we had to stick the apple pen into the iPad. I'm not sure how to interpret that psychologically. Developer egos are certainly a problem, but I don't think it's specific. We all have our egos and doing a good job for somebody else's needs is always a conflict of interest. What is more surprising, is that in software engineering, people are usually not aware that this conflict is there. Software engineering is not settled. We keep coming up with new paradigms, methods and ideas and we keep failing to meet expectations. I'm old enough to see that many new ideas are actually only thinly disguised old ideas with a shiny new name. When architecture was innovative, craftsmen commuted over continents and they had individual credibility to sustain their decisions. Architects had to stand under their construction when the scaffolding was removed. We don't have this kind of work ethics and such a concept of responsibility in our contemporary project management. And still, we have impressive videos on RUclips illustrating the concept of a resonance catastrophe. Don't be too hard on us. We're just human and that regrettably means we're pretty stupid.
The main problem is that the software is not meant to work as good as possible, it needs to earn as much as it can with minimal cost :D. C level stuff doesn't care about anything apart from KPI's they will sacrifice 50% of the effeciency if it will translate to 51% of increase in conversion rate by the new slower frontened
Sometimes experienced engineers that come onboard exhibit this very ego you are speaking of and it destroys the team dynamic. For a company, sometimes it’s about who you don’t let on the bus.
In Italy we have the exact OPPOSITE problem. No one is advocating for X database or Y technology, everyone just sticks to a software model from the 90's and no actual innovation is ever made, software is still shitty and buggy and slow, impossible to scale too. How does this apply to your argument?
The !Empathetic Engineer medium.com/@hnasr/the-empathetic-engineer-d8220030971b
exactly this career is exhausting because its not science its like philosophy , there is always an argument against and argument with , the optimal path is not clear , one must have power in team in order to work , knowledge or experience alone is not enough , because egos will be fighting all the time
most of what you are pointing out is accurate AF, but the source of these "changes" come typically from the parasitic upper management class that need to justify their existence in the organization
The tone of this video is different. I hope you’re doing ok Hussein. Just want to let you know that your content has been both one of my primary resources and an inspiration for the first 5-6 years of my career.
Yes same here I love these so much and I feel like his videos are such intimate windows into software devving from a really talented software dev
Same feeling, hope he is not going through hard times at the job
There were also MANY cuts in this video as opposed to what's normally a single continuous take. It stands to reason that he cut out a lot of particularly negative stuff.
He also looks absolutely exhausted - his eyes, in particular, are lacking his normal animation and passion. I hope he'll be able to get some rest, and perhaps new projects to focus his passion on!
He looks tired…
Same here
I started "Understanding the reason behind everything" mentality a month ago after knowing you!
Literally the most important skill any software developer should acquire.
How do you balance between "getting things done before estimate" and "digging deep into the topic" ?
@@bonniesimon14 can't even understand your question, clarify please
Thanks in advance
@@magdynasr6639 Sometime I want to dig deep into a problem. But due to time constraints I would have to take a pass and just solve the problem. How do you find time to solve the problem as well as dig deep into it?
@@bonniesimon14 That's a very tough question! depends on your situation, are a student or do you work? the answer to this question differs a lot. another one, what is your level, are you beginner, junior or even senior? based on these question you start to manage your time so that you make the most use of your time..
for me I am focusing on the knowledge as I am a junior sw engineer so I must gain knowledge as much as possible so that I grow healthy in this field.
SO back to your question
when to dig deep and when to skip?
the answer is: It 's always better to dig deep into a topic or a problem BUT if you have to finish a certain task for the sake of a deadline so just solve the problem but don't make it a habit! NEVER make this a habit
I hope my answer helps!
This is the issue of life nowadays. You see most of the people caring about the fancy things and leaving the essence.
Yeah true...
This is a mentality issue that is not restricted to only software engineering but exists also in other aspects of life.
I've been thinking a lot of similar thoughts recently. I think the field is just in a weird transitional phase. We very rapidly went from experts that could hold nearly all the abstractions in our heads, to now only holding a fraction of them. From having very predictable execution environments where we have confidence in our programs, to having to wrap all of our stuff up in protective containers to make sure they survive out there in the wild.
Back in the day, I think the ego was a very good thing. It allowed people who "knew their stuff" so well they could just work with their gut and move extremely quickly. But as we move into a more complex, generalized AI-powered online world, we're rapidly losing our ability to understand the entirety of the field. We still need some room to take risks and innovate, but could definitely use some more sophisticated methods and a more mature culture beyond "oh they're super smart, just let them go at it".
Agree, have personally experienced the scenario when as a junior engineer proposing a new approach and design which was discarded without understanding the impact and the performance gains, totally relate with EGO a senior has, which is generally combined with ownership and superiority.
the worst problem is with recruiting. They want someone who can learn but some one who has experience with all the technologies. how does that work
Just further feeds into the culture. You gotta embody the ego-centric-midset in order to get the job, then you embody it once you actually do the work :/
@@Spookyhoobster throwing some truth bombs 💣
@@Spookyhoobster in sort you have to say yes in their yes rather than showing different perspective. Because as you said they don't want somebody to know more atleast in interview.Not everybody is like that but most of out there. Correct me If I am wrong. 🙌
I think everything boils down to "REQUIREMENT".
If optimization is not a requirement, a developer might write the simplest working code and call it a day😅.
If crappy working code is "good enough", no amount of optimization proposed will see the daylight of production.
This battle of propose -> convince -> achieve for a "REQUIREMENT" to become "FULFILLED REQUIREMENT" is truly a hard one with lot of gray areas and for all the people who are battling these battles deserve my true respect and honour.
I love this. After 20+ years of software engineering I want to write stuff that just works and is flexible to real requirement changes
The starting point of over engendering is the word (flexible) 😂😂😂😂
i want too but I can’t because of three words (flexible-secure-smooth)
What field are you in to last 20+ years?
It's not always ego. There's many reasons why a good idea might not be implemented. Time, resource, risk, roadmap, product lifetime etc etc
If your idea is good and your tech lead says "Good idea but we're not doing it right now because X", that doesn't mean he has an ego about it.
On the other hand, if you have a good idea and he shoots it down without explaining why... that's a problem.
As the developer of a 2D game I have, many times, re-written my code that was perfectly working before just because I didn't like how the files were structured and/or wanted it to use this new paradigm or class that I made, rather than fixing one bug I rename 1359318509135 symbols in Vscode and never get any actual work done. These type of re-engineering has to be avoided at all costs, just get the stuff to work, and work well, and go about refactoring a little bit at a time rather than a sweeping action.
refactoring is a great way to get better at coding in general. you have to do what you're talking about to hone your preferred style. you won't get to writing great code by doing one-and-dones. but once you do write great and clean code then that will be your starting point for future projects. i have seen people do one-and-dones for years without ever understanding how to write great code or what the difference is.
Yep, I'm frequently guilty of premature optimization and I think a lot, or maybe most developers, scientists, technical experts, etc. are a bit obsessive and while it's a strength at times, it can also be a weakness unchecked...
Instinct tells you everything needs refactoring, but that should always go through a logic check. "If I refactor how much value do we get" "Does this value outweigh another task I could be doing?" and so on.
Often you'll realise that refactoring isn't as important as your instinct makes it seem. Especially for features that already work fine and aren't causing issues.
We had a folder structure to manage and store various projects that works fine our new boss came a and changed it just for the sake of proving herself then the whole server is fucked up, I gave up trying to clean it of fixing things
I can sense your frustration in this video. Hope all is good man.
I appreciate this video. I complain vehemently about these problems in modern software in the frame of mind of "them" - but I am one of them. This video is digging into the core of us-them.
The majority of devs get lost in their code and forget the end goal is just a happy user. Don't get me started on "developer experience", imagine a plumber saying "plumbing experience."
Well they do. Every day. They need working tools and if they are not working, something that gets the job done better, faster and reliably are taken into use.
If a plumber would forget that the end goal is to have a working pipe they'd tear up a wall just to change the color of the perfectly working plumbing. I think that's more the case here.
But you do need to test different pipes and tools constantly to know if any improvement can be done. So when do you test it? While working real job that generates revenue or invest in actual R&D type of activities that "only have a cost to run"?
I disagree developer experience is really important thing. Just like plumbing you need a certain setting to make your work properly. So developers also need certain setting to work efficiently. For example if your project is hard to setup locally that will impact negatively on dev productivity because they can't easily onboard. I think this kind of "developer experience" is important. You can't build a good product if you can't work on the product effectively.
@@jonijarvinen7833 nice thinking, I'm also sick and tired of people treating their projects as personal science fair experiments. Forceful pushing of things like distributed architectures for somebodys personal pleasure or marketing benefit completely ignores the tradeoffs. It's 'great' fun trying to salvage these trainwrecks as a maintenance dude.
exactly this career is exhausting because its not science its like philosophy , there is always an argument against and argument with , the optimal path is not clear , one must have power in team in order to work , knowledge or experience alone is not enough , because egos will be fighting all the time
Thank you. I have been sitting on this for a long time... this isn't Software Engineering it's Software Philosophy.
it's always the same story in any field, the industry just kills the Vibe, even this AI thing is something wanted by industries not even end Users, so good job humanity, we are going straight to the wall .
There's a lack of expertise today in software engineering making expert decisions. The barrier to entry has gotten so low and the latest tools/frameworks/techniques are rotating every year the software is suffering across the board
every design is like a local maximum that you have to climb in order to see how high it will take you
Never allow ego to take control, always stay humble and you will learn a lot of things.
We used to call that "Management By Buzzword". I worked for a big company with lots of higher up IT people (VPs, Directors, etc.) and they would talk. Our Director was NOT a tech person and had no way of evaluating one path over another. So they defaulted to talking to all the other "smarter" Directors. If one director was doing something and we weren't, we were suddenly supposed to drop everything and implement their new thing or have a damned good reason why we're NOT going to do that thing. From an individual contributor perspective, it was like being a pinball in a pinball machine!
But this attitude is not limited to non-techies. You're right that it's often based on ego without any additional supporting evidence or knowledge. We once implemented a solution that was easy but not optimal because we had to technical knowhow to make it happen coupled with a VERY small window to get it done and HUGE downside risks for missing our deadline. After it was deployed and successful, we brought others onto the team. Many of them immediately criticized the solution and were VERY accusatory and condescending towards us that were in the trenches at the time. Saying things like "You took on Technical Debt when you didn't need to" and "You deployed a solution that is not good, nor is it sound, nor is it robust nor is it.......well you get the idea. Any insult they could think of was hurled at us. BUT it was working and working well with VERY FEW issues. After a year, one of those people came to me and apologized and actually said that they were wrong for being so critical and that they actually liked our solution. It provided various features that we were now utilizing to actually broaden the services we were providing - services which would not be possible to provide with a different solution.
This is why I try NOT to criticize other people's work even when I disagree with their approach. They have reasons for doing what they've done and sometimes those reasons are significant and should NOT be dismissed quickly.
Hi Hussein
It seems like you’ve experienced some "we have to add this new unnecessary feature" BS at work this week. I can feel your anger permeating through the screen 😂.
Hi Hussein, where do you find these kinds of blogs? What sources do you read? Hello from Kazakhstan! Thanks! 🙂
I've seen this mostly with the new CXOs and PMs. They just know what should work based on their prior exp and they can't take anything new being done as an input.
So they make engineers do things like this most often.
And, I am sure the splash screen idea was also from these guys instead of 1 of the engineers as we know it's a 5 minute task to add a splash screen and doesn't bring any difference in our lives.
Been following you for nearly 3 years now. But In this video, you seem really low and down. You are one of the reasons that motivated me the similar times and have been a continuous inspiration since. You will bounce back 🙂again.
What I don't enjoy in OSS is the people in it. I come from a specific community that has this mentality - "your suggestion means nothing if you don't have PR with it". Even if the suggestion is as trivial as no code is needed to understand what someone is trying to point out. Instead, if you are a top guy/gal in that community, your PR can be as junior like as it can be and it will be merged, no questions asked.
I have noticed that whenever someone challenges that mindset, they get completely ignored and labeled as "hater".
Looks like the maintainers are not open to new ideas. That sucks.
@@skyhappy not only that, but they think that if you pay/support their software, you are no better than someone who doesn't. Like, you don't even deserve priority issue fixes even if you pay them. Then it's for open argument of - where does my money go? Does it go to your lunch and therefore, even if I buy you lunch, I cannot even get better support with your product? It was quite ironic to hear backlash on this, when the donation I gave unlocked part of their docs, lool
One more problem is when your team manager is not from tech background but pure managerial background. Its a pure sh*t show for that tech team.
I love your opinion.
You might find same opinion in the book: "The Pragmatic Programmer"
There's a lot of truth in this video. I've seen this in myself and other devs. Appreciate you addressing this topic
Altium studio had this happen. Went from old-looking but fast to modern-looking but sluggish. Fortunately I had hit the point of my degree program I was barely using it by that time.
I was recently hired in a company as a software engineer ... I noticed the senior engineers are very defensive against any new idea I share with them
At the same time I get worried if I'm adding those new ideas because of my ego or not
I think the best solution is to talk and argue over things and discuss what we value as a company or a team
Working from defining value in a product is very helpful in the beginning
Usually (let's say 95% of the cases) the reason why senior developers are change adverse is because their experience allows them to ponderate the pros and cons of such changes.
Let's take one example: You watch this amazing tech-talk about this revolutionary database Y that is so much better than database X, which your current company is using. On the next day, you go to work and tell your senior coworkers about this amazing new technology and how good it would be to adopt it.
Sounds familiar?
Think about it for a second. You just heard about this new database yesterday, and in the best case you also spent a few days researching about it before suggesting it to your senior co-workers. Now, let's say that on average, a new database comes out every 3-6 months. Can you estimate how many new databases have your senior co-workers seen come and go during their career?
Let alone how many times they have seen it, they were juniors at some point in the past and they also had these "amazing" ideas that they got from reading a book or watching a tech-talk.
The thing is that experience not only gives you a better sense for telling between what's good and what isn't. Experience also gives you wonderful lessons in the form of pain:
Do you know how painful it is to switch from one database technology to another? If you are a junior, you probably don't. But your seniors probably do.
This is a super-simplificated example, but I hope it helps you to better understand why usually seniors are change adverse.
Have you asked why?
@moy2010 Your attitude is exactly the type of ego this video is about. You went off on this person assuming their ideas are not worthwhile to even be had, let alone shared. You don't know them or how creative they are. All of your examples may reflect reality and you may have good points but your attitude and condescending tone is a manifesration of the same ego Hessein discusses in this video could stifle future communucation and hurt the organization.
“Ego” can sometimes boils down to feeling like you have to do something or prove something to keep your job. You then start coming up with useless features and criticisms (or dismissal of legitimate criticism).
This is a perfect explanation for MS Windows. Endless updates, long boot times, just like automobiles being updated and tweaked every year… it stirs the market and increases demand.
In the web mostly it is because of the new approach to development for instance using the single-page application approach. This approach makes the web application inefficient by making load time longer. I believe the good old HTML is and will be the best approach to developing web apps instead of using Apis
I couldn't agree more. I couldn't help laughing seeing SSR and now server actions in Next.js.
Hussein, woke up and chose to tell the truth. The raw hard truth.
Anything that is forced with out well targeted reasoning behind it fails ... Absolutely right .
i miss those times where there were some constrains, current day devs wont care about, for example a simple notes app that is around 300mb, just because of the frameworks
Memory is cheap. CPUs are now 7ghz
@@ea_naseer yes but that does not apply to every cheap device around
just a suggestion sir, can you please make a video on embedding vs referencing in mongodb, their practical use cases, that will be great if you do
Personally, I love seeing junior devs or those without as much experience come up with some great idea and it works. I encourage that all the time at my place of work. I think the fear of being out-shined and being considered less of an asset is the concern one would feel in that scenario. Collective success is important.
I feel exactly like the guy coming from outside with fresh ideas. But I'm also a senior developer, I know the pains in the field. I see the barrier of "let's use what we're used to" way too clearly - because I've been there in the same position - that's where I came from. I almost always have to abdicate of my own ideas to someone else just because this guy is there before me and I don't want to be the problem. But it's frustrating, I feel like in a prison having to accept that actually solving the problem is not that important for the company. So in the end I just let it go, and try to do my best in my own things - which is what really matters.
I find it funny that everyone in the comments talks about OTHER people, but don't introspect. I for example have noticed myself getting defensive without "real" objective reason about some parts of code I've written, I try to work at it but it isn't always easy to completely forgo the ego.
It used to be that IT was about CS, math and engineering. It was about red eyes and sci-fi.
Then Eternal September happened. BOFH is a perfect example of what followed.
And soon after money started flowing and hype began. It seemed like you could quickly write a couple HTML pages and become a billionaire! Or at least feel slightly better off financially in this modern unequal world. Everywhere you looked since "The social network"'s release in 2010, there's been this HYPE.
Tons of people who otherwise wouldn't've joined IT, decided to jump in and have their piece of the pie, be it stable income, big money, fame or just FOMO.
And how do you get promoted as an engineer? You add "rewrote from scratch", "implemented a pipeline" etc. to your CV.
How do you get promoted as a manager? You add reports, each of which wants to be promoted as an engineer.
The industry of mathematicians and engineers has become infected with HUSTLE, with people who need to prove themselves, to join or create a startup, to become a VC.
A similar situation, but even worse, is taking place in AI.
It used to be a quaint field, with career-seekers avoiding it like a plague, until money started flowing in, and suddenly the same people who before would never have allowed themselves to be seen anywhere near "these naive AI lunatics" are memorizing like crazy what cross-correlation is.
it's fun being an ego driven developer , it's liberating tbh
What a fantastic channel you have Hussein! I'm glad I found all of this information. Thank you!
reqlly good one…i agree with this and nicely articulated. adding few more…sometimes management puts pressure on the technical leaders bring in new tech …sometimes couple of issues in an app and people form opinion about technology being flaky but where as the problems are in the way code is written which can be fixed easily.
Anything you said in this video screams Discord to me lmao. Though I do hope you are doing alright Hussein, you seem like you've been through a lot lately.
For some reason to me too😂, i really liked the old one.
This video is eye opening and insightful, thanks Hussein!
the number of times i say tomyself, if i ain't broken, dont fix it. then there are the clients that want features that are more wishlist items
Are you doing okay Hussein? You seem a little down. Hope everything is ok.
Not sure how you're doing Hussein but you sound tired in this video, please take your time to take a break if you need it, I hope you are doing well
You are such an inspiration and we really appreciate your hard work to teach hard topics with such amazing detail and passion, but some times you have to give yourself some time to relax
I might have done a couple of things like this is the past. Relatable stuff.
It seems to me that ego is a bit of a pointless barrier and pain in the ass even for the person themselves. It makes you tend towards staying in your comfort zone and never learn anything new. The fact of the matter is things take effort to learn to a deep level and someone with a massive ego never wants to admit to themselves that they don't understand something right away. In the end they lock themselves into only understanding topics superficially
Can you increase sensitivity of your microphone
You are spot on my brother exactly what I recently experienced
Noticed MUSASHI in the background. A warrior in the making
thanks for sharing. will keep a note of this.
This is to relatable
It was my big issue with my engineering manager and ends up that I was the unlikely guy from him..
True mastery also means to know when something is finished, most people don't get this
Sometimes these are A/B tests 😂 maybe the new UI is helping convert more free users to paying users. I personally hate to see changes in UI to which I am super acquainted to.
A/B testing with your users without considering their experience is repulsive to me. It's just like your goal in your comment,
> "helping convert more free users to paying users".
If your goal is only that, you'll be losing more users.
love this video
IMO, reading the book "Ego is The Enemy" by Ryan Holiday is a must for every team leader if not every programmer
Great book IMO. I read it at a critical point in my life as well
Can you please put the members only playlist in a youtube direct link instead of shortening url?
It doesn't open in RUclips app.
(I'm a member with other account)
Love all of your content Hussein.
To raise the morale a bit with a joke, I think this goes to all jobs involve doing /creating things. Didn't ever happen to you for a plumber or electrician to came to your house and say "ooh, who did this? Oh my goodness this is all wrong and needs to be redone". And because you don't have so much expertise, you freak out. Hey I don't want my house to be set on fire or whatever.
Same here. It happen to me countless times to be put to the wall only by asking one simple question: "Do we need this?"
Do we need to go to the cloud? Do we need to change the database? Do we need serverless? Do we really need to REWRITE from scratch every time? To name just a few. To ego I'd add boredom. On my side, most of the times I've felt like people were straight up bored.
We want to leave something behind and this is why, I think, we do this push to change everything, something.
This is why you should go down the DevOps engineer route aka. the dark side where as long as you automate stuff you'll be considered a hard worker (my insiders heard rumors and leaks about automating your automation so you can slack off without being caught at work but shhh don't tell anyone)
They are just pumping any software with infinite numbers of features which comes in cost of performance, usability, glitches and keep doing it for the sake to keep rolling the ball
Thanks for the important reminder.
Great video. Love to see more on this topic
Banks will prefer to change their UIs 1000 times than to fix up their backend to be more efficient
I think software engineering field lacks educated people that know how to think, analyse, assess. It's not only about writing code or knowing some framework - being a good craftsman. As in any other field, you need to be able to see the problem, state it clearly, evaluate risks/benefits of solving it or leaving as it is and making a decision. It involves calculations, not only your gut feeling...
Two years ago I was a web developer. Now I'm programming chips and linux kernel tinkerer at work. What I want to tell you is web dev realm is so crowded and too many people who still in "mount of stupid" of dunning-krugger graph. I feel like the more high level programming developer, more ego evolved there. That's- just my intuition, let me know if I'm wrong
Never change sir.
You didn’t contradict yourself because you said at the beginning “It’s one thing when the app works fine and someone comes in wanting to change everything”. Also I’d recommend reading The Scout Mindset by Julia Galef. It talks about this problem on a broader basis. She calls this type of thinking the “soldier mindset” and it plagues more than just software engineers.
0.5s to 15s seems hella lot like migrating from a C++/C app using native OS components to Electron...
Trust me. I know what I'm talking about...
Duolingo added a 5 second splash screen if you have a Duolingo premium subscription.
So they chose to make the experience worse for paying customers, which is beyond my understanding
Aka Revolut. It's now super slow on my S10. No I will not upgrade my phone. I need a headphone jack and a microsdcard.
It drives me crazy when something so simple has to be 200 MB in size. I remember there used to be pride in the old days getting your application down in size and efficient but today it seems like absolutely no effort is put into making applications slim and efficient.
Yep. Hello World app in React is literally 300 MB
Mine was 260MB first Electron hello World! App
Thanks hussein. Just love your content.
Hey, Hussein! Thx for the video! I think you are really touching an important issue with software development when talking about a developer's ego. Regarding this, what would you suggest to do to mitigate it?
A better hiring process? A better process for building teams? Or perhaps a policy regarding engineering decisions?
I think you answered your own question. A few simple tweaks in the hiring process, team building process and engineering decisions might do it. Great question btw!
They say brand taste and meaning to the brand or whatever the webapp is about , do makes sense sometime in frontend , not always yeah that's definitely true
That's why software engineer are paid more, cause investor thinks changes means company is working. As they can create new software every 3 month
I've always wondered why does the instagram app change so frequently :/
Instagram in a nutshell. Every week there is a restructuring of the UI, and not for the better. They keep removing useful features (I miss sharing a comment on a post to a chat), and keep adding crap features no one asked for.
IMHO it's often more complicated. What if you can't judge the benefits of an improvement beforehand? What if the majority of the team is against a good change? Would you make their egos unhappy to make justice for just one other developer? Recently I joined a team that I'm extremely out of tune with. We disagree in most cases. Are they egotistic? Not clearly. Superficially they are what you'd call an open and empathetic developer. At the same time, I feel constantly micromanaged and programmer-splained. It took me a while to figure out where's the problem and why it's in 100% on their side 😁 I'm half joking. In the end, I decided we're irreconcilable. We just don't fit. The moral of the story is: know what coding style and practices you are willing to accept and ask about them during your job interview.
You have to update the code - otherwise, the code will become stale. The team must be current in their codebase - or no one will remember how to work with it. Libs and technologies involved in your project are updating, and getting old bugs and vulnerabilities fixed - so you have to update your project too, adding new features by the way. This lead to increased complexity of the soft, and often to slacker performance.
Low key title is actually "the problem with software engineers" but that would be a series.
I think also with the current job market has made it worse. Everyone has built bigger egos trying to prove that they are the best amongst a competitive pool of candidates.
Seen so many bad codebases in past decade, problem with modern day workflow is everyone wants to jump in cutting edge tech without evaluating pros and cons. They often forget that individual teams have their strengths and weaknesses.
Good softwares are built on top of their skillset and expertise. Proper implementation and execution weighs more than getting out a product with buggy and half baked implementation as alot of those resources would be struggling with new language or stack.
What I've found is, older softwares tend to be more stable in nature from begining because alot of them were not agile and followed software engineering practices that made these impmentationa more reliable and resilient towards unknown factors as those things were evaluated at very early stages of development. Modern day workflow is quite opposite and in the name of growth, innivation, it is going to cost more in terms of tech debt and bad codebase that newer maintainers will inherit or probably will be scraping in name of new implementation.
Like it or not, unless you are a developer, software engineer, architect or someone building software, no one else in chain give a dime about how it's going to be impmented. Whuch makes it harder to take good decisions based on long term outcome. Often engineers and tech people have to convience them to make a sane decision which is in between and never good enough to throw out old garbage.
Yesterday's experience : Instagram forgets to add save button in bio edit screen. "Yes we have automated builds but no good QA so you get app pushed on app stores without much oversight!" - why? Because all big tech love automation that they forget basic engineering practices. There are plenty of such examples. That's the reality..!
Was thinking the same mate. U summarized it well😁
I’d just add that even old software is not gold. It just had less going on. It was simple like frying an egg.
Modern software is like getting egg whites from a carton, then putting it in some machine, that then turns it into a 5-star gourmet omelette. All you wanted was a fried egg but you got something different with all of the headache of maintaining the magic machine and paying for the cartons.
Abstraction and task offloading are both blessings and a curse. If the machine isn’t working, you have to troubleshoot that on top of your own stuff.
Old school software was easier because you knew what you wanted from the get go, then planned to attain that. Whereas modern is like: you might want an egg, or an omelette, or a cake. It has to handle all these cases cause we don’t know what you want and neither do you.
I think you overlook an important aspect here. Most software developers do not actually develop software, they develop modules. They/We are very far from users and their needs. The best software usually started with an individual or a group who developed a solution for their problem. They had both the purpose and the means and that's why their products are good.
We invented the term "product owner" for the role in a software project that creates that connection between the actual users and the product. Since we adopted this terminology, I did not see a single person who filled this role well. Businesses apparently do not really value this function. You can see that at Apple. Shortly after Steve Jobs left the company, we had to stick the apple pen into the iPad. I'm not sure how to interpret that psychologically.
Developer egos are certainly a problem, but I don't think it's specific. We all have our egos and doing a good job for somebody else's needs is always a conflict of interest. What is more surprising, is that in software engineering, people are usually not aware that this conflict is there. Software engineering is not settled. We keep coming up with new paradigms, methods and ideas and we keep failing to meet expectations. I'm old enough to see that many new ideas are actually only thinly disguised old ideas with a shiny new name.
When architecture was innovative, craftsmen commuted over continents and they had individual credibility to sustain their decisions. Architects had to stand under their construction when the scaffolding was removed. We don't have this kind of work ethics and such a concept of responsibility in our contemporary project management. And still, we have impressive videos on RUclips illustrating the concept of a resonance catastrophe.
Don't be too hard on us. We're just human and that regrettably means we're pretty stupid.
I feel like there is some background to this video, something Hussein hasn't mentioned.
Couldn't agree more 💯🎯
The main problem is that the software is not meant to work as good as possible, it needs to earn as much as it can with minimal cost :D. C level stuff doesn't care about anything apart from KPI's they will sacrifice 50% of the effeciency if it will translate to 51% of increase in conversion rate by the new slower frontened
It's so true! Totally agree!
Sometimes experienced engineers that come onboard exhibit this very ego you are speaking of and it destroys the team dynamic.
For a company, sometimes it’s about who you don’t let on the bus.
13:33 "I think I wrote a book about it." 😄
Solid video man. Very real
As someone that still uses Photoshop CS3, i get you
Writing good performant software requires skill, understanding and expertise. It's much easier to chase the latest shiny toy promoted on tweeter.
Software engineering has become about solving problems that software creates.
In Italy we have the exact OPPOSITE problem. No one is advocating for X database or Y technology, everyone just sticks to a software model from the 90's and no actual innovation is ever made, software is still shitty and buggy and slow, impossible to scale too. How does this apply to your argument?