Why Are You Making Programming HARDER?

I hear a common complaint that programming has gotten harder over the years.
The more years I spent in software development, I fell into getting frustrated and blaming other people, or the technology.
But I realized that I was a big part of the problem - though it was hard to admit.
In this video, I share some things I didn't realize at first that I was doing to make my job harder than it needed to be.
0:00 Introduction
01:55 A History Dev Innovation Theory
04:44 Gut Checking Complexity
06:11 The Framework Explosion
09:00 Why Are We Making Dev Harder?
09:06 #1: Fear Of Career Irrelevance
09:48 #2: Underestimating Learning Costs
11:37 #3: Intellectual Masturbation
13:09 #4: Immaturity in Technology Selection
Subscribe for more videos about Healthy Software Development: kzbin.info...
Related Videos:
"Technology Addiction | Materialism in Software Development":
• “New Framework Disease...
"Are You A Perfectionist Programmer?":
• Are You A Perfectionis...
#programming #career #complexity

[@HealthyDev]

How are you coping with our need to grow without making programming harder? Skip to points: 01:55 A History Dev Innovation Theory 04:44 Gut Checking Complexity 06:11 The Framework Explosion 09:00 Why Are We Making Dev Harder? 09:06 #1: Fear Of Career Irrelevance 09:48 #2: Underestimating Learning Costs 11:37 #3: Intellectual Masturbation 13:09 #4: Immaturity in Technology Selection

[@user-it8yh8tu7d]

Why cant we replace all of the C code with assembler macros? It gets compiled to native code anyway.

[@zackplauche]

I don't think people will understand how amazing this video is. He just saved you years of your life.

[@HealthyDev]

I'm not sure I could really hear (or internalize) this advice for the first 10 or so years into my career, so I don't expect everyone to get value out of it! Glad you did :). Thanks for the encouragement.

[@ManojSingh-dm2jy]

Man, you are the only person telling truth about software development. Rest of experts are just fanning latest tech hype to earn money, and attend technical conference in Las Vegas. I find your videos as stress buster. You will not get money by telling truth, but you will definitely get blessings of many software developers , around the world.

[@dhruvshetty2127]

This reminds me of how now everyone’s trying to solve every business problem with machine learning or deep learning algorithms because they can and it looks sexy when they can just define the problem and hypotheses better and use linear regression or trees or even sql queries which are faster,use less resources,interpretable,you get the gist because it’s like us software developers are just not used to think about outcomes.

[@HealthyDev]

For real. It’s hard to see the forest for the trees when there are too many different types of trees 😉

[@monad_tcp]

I'm doing the opposite, I use simple statistical algorithms and call them AI, so that I don't have to waste my time trying to train them, I'll do perfectly what I want, mathematics, it works better when you do with, instead of letting the machine randomly approximate it for you. AI is just convex optimization of polynomials. AI Winter 2.0 is coming !

[@aaronbono4688]

I have a project where they wanted an engine that understands free form text to order food. They wanted it to understand the whole English language. I told them no, just match up the food words and add to order (it is a tiny bit more complex than that but that's how it started). It runs fast and is super accurate and it cost 1/10 of the cost of all their other estimates. I told them they can worry about machine learning once they had a ton of customers and revenue to make it happen. But we still use the same approach we started with.

[@HealthyDev]

@@aaronbono4688 yeah sorry to hear this. Delivering minimum viable products and iterating on them is harder than most people realize. There's a lot of fear that goes into letting your idea out there without "all the bells and whistles". I've seen some companies do it better than others for sure.

[@aaronbono4688]

@@HealthyDev I think you misunderstand me. My point is that the system does not need artificial intelligence and that the simple approach is what is best. I'm actually very happy with the way the application works and I'm pointing out this is a prime example of how if you keep it simple stupid (KISS) you can do much better than if you go hog wild and spend tons of time and money with sophisticated solutions which I believe probably would perform worse, at least in this circumstance.

[@basteagui]

this is the guy that really speaks what you need to hear on youtube about these topics. i don't listen to advice just from any of these youtubers but this guy really knows what he's talking about

[@minjadavidovic5153]

It also seems that a lot of technical decisions are heavily influenced by marketing.

[@aliensarefromspace]

I was on a project that was forced to use Kubernetes by our Product managers, just because "All the big players are using it".

[@karoshi2]

In the company I'm currently working for it seems like the techs are trying to optimize their own marketing value by introducing new products, stacks, languages, ... constantly. Ended up in a mess of mashups which basically nobody understands anymore, thus we need the new shiny thing to fix this, ... Resume: catch-22. 🙄

[@nuvag8832]

Yes, today everything has to be "Blockchain, Big Data, Cloud, AI" ;-)

[@MrAntice]

I inherited a project that marketing forced through because (buzwords). Hating every second of it. It's a completely different tech compared to all my other projects in the company. It's not bad tech. However it puts a lot more pressure on me to maintain it when it's a completely different stack using proprietary solutions that aren't used anywhere else. I can't reuse anything at all from the other projects, even for the exact same problem that needs to be solved.

[@afhostie]

There's 2 problems I see that exacerbate the issue: 1 Resume-Driven Development gets more promotions 2 Businesses are more apt to give adequate resources when you're introducing "shiny new thing" It's also a lot easier to convince people that something will magically solve their issues when they're constantly hearing buzz about it in the industry (block-chain, ML, agile). It's a lot harder to convince them that they just need to give reasonable timelines and staff to a project and adjust the timeline when they inevitably change their mind about the number of features included in the project.

[@careya]

I’ve worked with developers who always want to write their own custom packages instead of using existing libraries. It’s fun for that developer, and a great learning experience for that person, but it’s usually a disservice to the project, the business, and fellow programmers.

[@HealthyDev]

To be honest I did this a lot early in my career. Had no idea of the level documentation and examples necessary, nor the evangelism and support needed to really get a home grown framework or library adopted that's of any significant complexity. I try to use off the shelf first whenever possible these days - clients pay me for business outcomes, not the Sisteen Chapel of architecture ;)

[@theguy9067]

Often people underestimate how much effort it takes to create fully functional libraries. Often I will first look for a solution that has already been solved. Conversely, if you ALWAYS think that you need to use third party libs, that's not great either. Often third party tools do too much or more than you need depending on requirements and people overestimate how much time it would take to create something that should he simple

[@MJ-xl5jz]

And then there's some companies that force you to write everything on your own because a third-party library is such a security vulnerability that it cannot be 100% guaranteed to always work fine in the future ☹️

[@twicfall]

Sadly, there is more to this issue. At first, using already-made libs to solve your problem can be a time saver, but can also cost you more time. You need to evaluate time to adapt vs. time to self-implement. Another big issue, that especially curses the web today, is that often a library solves many other things than you try to solve for yourself. That means you create dependencies on code and abstractions, that would not be strictly necessary. This can result in longer build times and more maintenance, as external library API's can change over time, and to keep them secure, you need to continuously bump to new versions, which can involve breaking changes.

[@mrcrackerist]

There is also the issue about importing a big library for a small function/method that could have been solved with 15 lines of code, the major problem I have faced is that when using to many libraries time is wasted on learning those new libraries, instead of implementing something very simple in about 10 minutes.

[@davethorn9423]

This is good dust , I am so guilty of this. As a self taught guy , I know modern frameworks but man I've only realized I need to go back to basics and learn that

[@Cons-Cat]

Wow! Every single point here hits me way too close to home. XD

[@alexplay3]

Completely true. The thing is today, the majority wants to apply all existing frameworks into 1 project just for the sake of using the latest, instead of stopping and asking the question: do I really need this new technology? I feel I still can defend myself with the bare basics, and just integrating very specific tools and frameworks to the projects. If it ain't broken, don't fix it, unless it can really be optimized, and if such optimization is worth it. In the end it's a productivity killer, having to juggle so many different concepts just to do simple things, it's mentally taxing.

[@HealthyDev]

Thanks for sharing your insights. I agree. I think the tech industry is partly responsible for this, especially vendors that want newer programmers to feel they are missing out, recruiters who want to sell hires in for the latest thing so they get a bigger cut, and training companies that need to expand their available offerings. It’s not that these groups are being purposely nefarious per se - but it’s something we probably need to think about the implications of as a community.

[@alexplay3]

In the end it's all due to marketing, everyone wants to sell desperately, but no matter how much marketing you do to a turd, it will still be a turd. I feel there's too much hype and no intrinsic value for a lot of things done today, just to sell.

[@anonymousbeast3486]

Yeah, it do be like that. I actually call it CDD which translates to "CV driven development": Use "cool" new technologies just to put them in your resume/CV and impress people/employers.

[@brettsartain6889]

This was really great! Thank you for saying this. As a Front End/Mid-Level dev, I can't begin to tell you how complex the projects I work on because the Seniors who wrote it think it's cool. Like you said, the point is to get the job done and leave behind something others can understand.

[@HealthyDev]

Thanks Brett, this took me embarrassingly longer than it should have to realize... 🤦🏻‍♂️

[@akivaliaho5166]

You can spot a true senior engineer by looking at how he approaches a problem. A true software senior engineer is obsessed with making it as simple as possible for the new guys to understand what he has been doing. This is because he has had to coach those new guys up to speed at least multiple times and it's an annoying experience if you are busy at the same time :D This way of thinking leads to a certain aspect of empathy. You start caring about other people and it shows in your code (and work in overall)

[@brettsartain6889]

@@akivaliaho5166 Very well said.

[@akivaliaho5166]

@@brettsartain6889 hah, unfortunately it's too laissez-faire (or easy to change jobs) nowadays. Some people never get to experience the burden of maintaining highly overengineered code. See, it's not so funny anymore when you are not the one experimenting. Doesn't get your creative juices flowing quite the same. It's easier to learn the latest hype tech and fly to the next green fields instead of taking genuine responsibility over your work.

[@edcoronado]

I’m 7 years into my career and recently became dev manager and these are all great things to look out for in senior+ devs. Great content.

[@ryanbell5213]

Wow. I love your outlook on CS. Great content, I can't wait for more!

[@reljodoreta5203]

This is really gold! Thank you so much!

[@jamesbond_007]

Amen to this! I just hate when coders do "science fair" projects -- where they shoehorn in some new tech or stack or whatever just so they can put something on their resume, regardless of the cost to the rest of the team in terms of complexity, lost productivity, maintainability, etc. I've been at this industry for almost 40 years as a full time professional, and I've seen this time and time again. When I see is happening now, I try to snuff it out (nicely, but assertively) as fast as possible because I know how this story inevitably plays out.

[@BillClinton228]

Or when they add tons of complexity to existing code so they can sound smart/more productive to management. Simple CRUD shouldn't be buried under 10 layers of abstraction. And then management tries to one up them by coming up with some insane rule like "if statements (and even tenery) are not allowed"🤷‍♀🤷‍♀ cool bro good luck with that

[@jamesbond_007]

@@BillClinton228 Yep. LOL @ not even ternary if operators -- someone's drunk the OO Koolaid a little too much there! Unfortunately, there is far too much of this "padding the code" with unnecessary tech or layers of abstraction, and not enough principal engineers to design and code review the code to weed out this resume-padding fluff. Unfortunately, the distinguished engineer at my last job was promoted to that role too quickly, and he was still in the "let's use all this wowie-zowie technology" (and have to spend inordinate amounts of engineering to shoehorn the tech into the existing build infrastructure). Bah!

[@eritert]

I came from a design background and it’s the same thing there, you have to escape your ego and be able to discuss your own work objectively in order to really flourish. I still have not done that in coding but now that i have seen this video i know what to work towards. Thanks.

[@olegsuprun7590]

Jayme , this is pure gold. The industry of fresh devs (like i am) needs you and your wisdom! You went throught all the hard work and frustration, to teach the younglings and move the industry forward. Thank You!

[@HealthyDev]

Thanks for the kind words! I’m sure you’ll have much to offer even though you’re newer to the field. Insight is much more valuable than knowledge in our industry and that can come from anyone! Cheers.

[@monad_tcp]

Some time ago I realized that removing things, libraries and striking for the most simple solution is actually hard to pull and if there's a skill worth developing is that (tools and frameworks come and go anyway, even languages nowadays). This resonated with me.

[@agoogleuser6959]

Libraries are generally built to be simple to use, though!

[@monad_tcp]

@@agoogleuser6959 yes, the problem is when you start pilling them one on top of another. they are never made to be easy to be composable (there a fine line between library and framework).

[@akivaliaho5166]

Absolutely. It''s easy to glue complexity on top of complexity. Figuring out how to prevent your project from devolving into that is hard as heck. I would say in the modern development world 90% of your time is spent on understanding how the third party library operates and how you can glue it together with an another third party library to accomplish something. This rarely leads to the simplest possible solution because you are adding the bells and whistles of that library into your codebase (+ your glue code). Programming should be about managing and limiting cognitive burden imposed on you as a dev not deliberately increasing it.

[@monad_tcp]

@@akivaliaho5166 Yes, developers that use too many libraries think they are delegating their responsibility for behavior, when in fact they are just losing control of the behavior, they transform the engineering of the software in a trial and error endeavor, I guess this does indeed decreases cognitive burden, instead of planning and thinking for a couple days, you don't have to think, just bash things together and eventually they will barely work, then spend the next year fixing bugs, because that's fun. It does produce bad quality software though. I like to work smart, to gather requirements and carefully craft just the code needed to solve the problem, sometimes you go search for libraries, but most of the time you waste more time testing them and fitting things together than just cutting simpler code fit for purpose.

[@akivaliaho5166]

@@monad_tcp sooner or later I find I need to scroll through the code of the framework / library the previous genious (or I am :D) using to figure out why something obscure happens. This is to return sense of control. Documentation is usually borderline horrible. This is always a tremendous waste of time.

[@ThunderhorseGuitar]

I'am by far not as experienced as you are(almost 6 years in this career) but i recently get more and more the feeling my code must be easy readable for consultants who may not know coding or have older code knowledge. So programming can have kind of social quality too. Thank you for your insights.

[@alexandrudanpop]

Don't know if you still read the comments but I really liked your content - very good videos about topics in software development not many talk about.

[@HealthyDev]

I do. Thank you!

[@Novacasa88]

Thanks for this. Many videos on coding are pretty much solely focused on the technical side of things and this is really helpful for me since Im struggling with a start up. My business partner gets very alpha and domineers over me while I'm trying to code and to compensate I subconsciously go for more complex and pretty patterns etc in order to compensate for his belittling demeanour. Its not helpful for either of us to behave like this but I can only control myself.

[@akivaliaho5166]

I'm very fortunate I managed to think this through very early on my career. I think it saved me a ton of stress.

[@HealthyDev]

That’s fantastic! 👍

[@cthree87]

100% true. The older I get the simpler and more degenerate my designs and code become. I let go of my opinions about what was "good" and "bad" and now I use the simplest tool that meets the requirements. Programming languages describe problems computers can solve in a way that is understandable to humans. If your code isn't readable by humans it's junk even if it compiles down to ideal machine code. What's that saying about how anyone can write code a computer can understand? I also think the biggest problem many code bases suffer from is future-proofing. Future-proofing is a fools errand. The Pragmatic Programmers call this YAGNI (You aren't gonna need it). A huge % of the code that gets deleted from a project never needed to be written in the first place as the users didn't ask for it or it solves a problem nobody has. Wee need not to write code that will be unused and deleted. That is a complete waste of time and energy. If in doubt, YAGNI.

[@HealthyDev]

I’m a big proponent of YAGNI too. Thanks for bringing it up! Great feedback and points. 👍

[@colbr6733]

Still great advice, with lots of really sensible questions to consider. Some of us have been lucky to be part of a group that strides across the if it ain't broke don't fix it approach with an opposing requirement to push entirely new technologies into the marketplace. Analysing any potential benefit to the business should also be driving the consideration.

[@joserobertoalanisbaez]

This happened to me. I had to follow management and refactor some code from C to C++/Java for upcoming projects. So I was the only one designing OOP in the team. Right after I finished this refactoring, I landed another job. My colleagues had a really hard time when they needed to contribute or troubleshoot the new C++ component.

[@BittermanAndy]

Programming is much, much simpler than it ever was. Keeping up with all the latest fads and flavour of the month tools and frameworks - that's become impossible.

[@chrischoir3594]

frameworks and tools are the problem

[@nathanlonghair]

It’s super interesting because I’m not “a programmer”, I’m a 42 year old guy who’s had a finger in programming since I was a kid. Starting with mostly basic, markups then php, asp, bit of js, vb and now the NEW one: C# 😂 I’m not good at any of them but I can hack something together. But the thing is; one of the reasons I’ve never gotten deeper into it is because I want to learn how to do stuff NOT constantly new techs, and it seems like I can never catch up. I’ve always felt that whenever I talk to anyone they’re working in something new (to me) that I don’t understand and then I just get another thing I have to learn to “get started”. Logically I understand that this is a trap and the important thing is doing anything at all, but still it’s super frustrating watching this constant accelerating chase for new tech for the sake of it, on the sidelines. Because invariably I will find out this: The new tech they praise? It’s still “just programming”. There isn’t anything revolutionary in it, it’s just a different way of reaching the exact same goals, and they’re not necessarily easier or clearer.

[@tanglesite4461]

I think the key to finding the balance that everyone is talking about really comes down to a couple key principles. One, is deferring. The big problem is trying to predict the future. Programming is not something you do in one sitting. You rarely know that a particular pattern will work until after the code is written, and then you go back and refactor. "Hey we can take this and stick it in a Facade." or something similar. Deferring the big decisions until it is absolutely necessary to make them. Defer defer defer. When you don't defer you end up with a overly complex architecture, chained down by three frameworks, and the three design patterns that you always use for everything. The second is differentiation. Being able to recognize the rate at which a project is changing, and acting accordingly. As coders, we are active, and not very often reactive. Lets face it, we write code because we like being in control. We like creating things and making them dance. But too often, a project is a living changing organism, and needs to be tended too, it needs to be reacted to. So I guess what I am really saying, don't make to many decisions too quickly, and code in response to the rate of change of the project, and not as the project changes. Hope that makes sense.

[@HealthyDev]

I love your perspective Joseph! Very reasonable and grounded in reality. I’m curious what you’d think about another video that I’m hearing a lot of parallels to in your response (related to emerging code and predictions to make commitments) if you haven’t seen it already: kzbin.info/www/bejne/pme5hnt9mpZ7q7c

[@tanglesite4461]

@@HealthyDev That was a good episode! I really like the person aspect that you put on an industry that is too often pigeon-holed as a impersonal, cold, nerdy, and aloof, etc...When really programmers are really just people. I will admit I have my run in's with the 'GOD' programmer, who knows all and sees all, he like eats assembly language for breakfast. Lol. But seriously, I think people often do not know how to deal with anxiety, they don't know how to communicate anxiety, or how to communicate through different levels of interpersonal relationships or just interpersonal communication in general. I took a interpersonal communication class in my first year, I really learned a lot on how to reach other people. And I think that is a key point, REACHING people. Communication which goes hand in hand with commitment, is not a skeleton key, it does not work the same way on every person. And at the same time, there has to be a a sense of command, it can always be a pat on the back, at-a-boy, better luck next time, ... I like the incentive idea, that really works, having metrics and incentives. There was so mush in that video, I could talk about this stuff all day. I love the industry. And I understand that people are ... fickle ... people are like using a pointer with no assigned value...you never know what you are going to get on any given day, you don't know what garbage some else left there the day before. But programming is definitely not a linear process. I do not know a lot about the business, but I do know that a project is not static, and you do not handle dynamic en-devours with a board and a ruler. I think communication is the key. Being honest, upfront, and setting honest and realistic expectations. I have always said relationships are all about doing what you are saying going to do. The flip side of that is, I can only expect from you what you tell me.

[@HealthyDev]

@@tanglesite4461 many of the conclusions you've come to are rare in our industry and wise. You're already way ahead in the game!

[@inexplicable01]

in this world of programming hype, thanks for trying to keep us grounded.

[@Kenbomp]

Nice. The view count shows the tech culture headwind to reason. Though the managers have allowed this as well or probably had a hand in started it with the org struct. This is why it's probably necessary for devs to do a hobby like music or theatre or gardening to counter the robot mindset

[@kdietz65]

I totally agree with you. My entire working modality is built around streamlining processes, removing complexity where possible, managing and abstracting complexity when it can't be removed, and generally trying to make it as easy as possible for developers to add functionality and business value. I think back to my last employer. So many things they did seemed so much more complex than was needed. The DevOps process was the most bizarre thing I've ever seen. One thing I've noticed that everyone is giddy about today is Docker. They love to containerize everything, and I understand that from a deployment standpoint, from a development standpoint, man, it really complicates things. My process, I just check out the code, set a few settings in a JSON file to point to my external dependencies (like the database, etc.), open it up in my IDE, hit Ctrl-F5, and boom, I'm running and developing. Not there. Containers. Proxies. Tunnels. Microservices. All manner of grief. Definitely felt like using a canon to kill a mosquito.

[@genericdeveloper3966]

This reminds me of a start up doing the exact opposite. Small team, this guy just created his app using tried and true tech (RoR, jQuery for a Shopify app) because that was all that was needed. It not only made development faster for him, but when they hired me I could get working on features immediately with little complication. That isn't to say there is never any value in the new frameworks, but by not using anything fancy when he didn't need it, the guy was making a high 6 figure salary and able to hire people to boot.

[@nathansloss1919]

I really like this! I worked in construction for years and every construction worker that ever swung a hammer thinks that he is gods gift to building and nobody can build as good as them. I imagine its the same in any industry. Coding is easy, its the people that make it hard. probably ego gets involved somewhere. I'm glad you make these videos.

[@thefather8362]

My favorite is when a developer learns a new skill or tool and then tries to apply it to everything.

[@bruinjim1]

Yeah, I've seen all these. In one company, there was a guy who spent two months building a simple database app. He included all kinds of stuff that just over-complicated it and didn't even finish it. He wasn't there long. I rewrote it in two days to a single file that's easy to understand. The best way to fix ego is to do something like that. Take someone's code, rewrite it in a fraction of the time and make it far better. A brutal wakeup call. Too many libraries and buying into industry hype/the latest trend also makes a mess. Programming is simple and should be simple. The worst part of this is when a library is no longer supported. Then you have to go back through your code and replace it. Pushing new architecture into a product is also dumb. We completely agree on this and all points. I'll add a few more though: Hacked up code is the worst to support. Try to fix something and ten other things break for no reason. You have to search through the entire code to see why. Then you're left with fixing the code properly or hacking in a temporary fix. Most coders just hack a temporary fix, making the problem harder and racking up technical debt. Another thing that makes code harder is having too many rules or procedures in a company. I've worked in places that forced a five min bug fix to take two hours. (Overhead for paperwork, asking permission, etc.) That gets frustrating really fast. Stupid ideas are another one. A client could want it done in a particular way, or your boss, and it horribly complicates things. Out of order development also creates a mess. If you have two months of custom library development to do before starting a project... (Actual custom library because you can't find anything that does it.) And the client demands to see an interface first... That generally complicates everything. Another bad problem are frameworks themselves. There are times when a framework makes sense. For example, if you need specific functionality throughout an entire project. And you know it's not going to change, so writing a framework or using an existing one makes sense. There are a lot of projects that start out that way, but they invariably change. Sooner or later they want to do something the framework can't handle. Frameworks only make sense when there is reduced functionality, but people always demand more. So frameworks end up over-complicated. If you develop with a mature framework, you often end up using the same amount of code as if there's no framework at all. The framework just adds a huge overhead and barrier to entry. Then comes the fated day... The guys who made the framework realize it's a huge beast they can't update any more so they drop support. Now you have a product that has to be completely rewritten. Overall, it's tough to say which one is worst. Each adds a different amount of technical debt. Then you reach the point of trying to fix the technical debt or rewriting it.

[@Diginegi]

It’s all matter of balance. On one hand I wouldn’t like to use Pascal or an early version of Fortran for any modern kind of development, but also using the latest, greatest, bestest new language or framework. What we create these days is much more complex than what we were creating 20 years ago, so it’s useful to have more sophisticated and flexible ways of making things work. I tend to follow a simple rule - assume whatever you’re writing is not entirely correct and will have to be changed (or replaced), thus make things simple (but not simplistic) and easy to change. The worst kind of legacy code I worked on was when the author was being too clever by coming with this amazing solution, that cannot easily be changed. It’s matter of time before it has to be changed. Always.

[@HealthyDev]

Good feedback, I agree with a lot of your insights. One thing that’s kind of changed for me is I used to make code more flexible in case it needed to change, but more often than not that ended up being wasted effort. I lean towards trying to use off the shelf patterns as much as possible, and tend to follow YAGNI. But overall yes, I’m not advocating for stopping innovation I just think we often innovate in areas where the value of the “improvement” is actually trivial and it ends up costing more than it’s worth. Yes I wouldn’t want to be coding in pascal or fortran today either!!!

[@camilocasadiego5509]

My wildest one was a company, that used mule and oracle sos suite, but wanted to build a "lighter" version for commercial reasons with spring integration, and the cherry, was the lead architect saying that the reason the project was so behind, was because the developers "didn't get him"

[@odenkaz]

damn, i felt this video to my core! Guilty af of doing all of this....

[@jonhartway8546]

That part about the enterprise event bus really cuts deep 😂

[@djoleluk]

I agree completely.

[@aivascu]

While I find most of the point in this video to be valid, I have often found myself coming into a new codebase that ignores, almost like on purpose, every good practice out there for clean code. I mean classes with 5-10K lines, functions that are a few hundred lines of code, little to no test coverage, giant store procedures no one even tries to understand anymore. When I tried to propose "another way" I was blamed to be elitist and just wanting to play with technology. I'm interested what would be in your view the way to approach situations like this? Or maybe if you've come across this how did you handle this situations and what worked better?

[@HealthyDev]

I’ve come across this situation many times. It’s a difficult situation, and requires subtlety and patience. I don’t know enough about your unique situation to offer much in detail, but one of the videos here that might help you is about earning trust with a new team before you suggest changes: kzbin.info/www/bejne/sKbJiXeEgLV7eZY

[@Zoltag00]

Really good point - We need to move away from the concept of crafts-people in favour of becoming engineers. The difference between these positions is the ability to write beautiful code and the ability to write beautiful code that *anybody* can understand and update

[@sosasees]

I never encountered this problem. Even before I ever watched this video, whenever I realized that I could simplify my code, I actually simplified my code.

[@HealthyDev]

Nice, you're ahead of the curve! 🙌

[@PedroAlvesM]

I like to studie new patters, technologies and stuff, but that's for personal satisfaction. When I am working is different, there need to be a separation between what you as an individual wants and what the work;business really needs. In your on Labs you can create crazy architectures, validate your knowledge and all, but on the work you need to deliver value, with the least amount of time and money spent.

[@rjacobsen0]

At 12:30 you say you can come into a codebase and learn the existing patterns and crank out features. How? How do you do that? That's the skill I need to learn. How do I learn it? (Please don't say by doing it a lot, I have been doing it a lot and haven't figured it out yet.) Thanks. Good video!

[@HealthyDev]

The more different industries you're exposed to, the quicker it can be to learn the unique things to that business that are represented by software. Eric Evans' book "Domain Driven Development" is a great one to help with that. And the more different architectural patterns you know, the easier it can be to break apart the frankenstein of a product's architecture into understandable pieces. Another great book there is "Patterns of Enterprise Architecture" by Martin Fowler. I hear what you're saying about "please don't say by doing it a lot, I have been". I don't mean to sound dismissive (and I understand your frustration!) but you do just need more experience. I don't feel like I even BEGAN to get comfortable with this until at least 10 years into my career. That number could be shorter (or longer) for you, but there is no silver bullet shortcut. I've been doing this for 24 years, and it's still hard. I'm a lot faster than most people I run across - but I still wouldn't call it "fast". Comprehending an existing code base is hard work (as you've experienced). I hope those two books above can help if you haven't checked them out yet! Best of luck Rebecca.

[@hiftu]

So much truth in this video. The company (industry?) forced us to use Kubernetes as the platform. We have around half the previous speed. And it won't increase back. It just add so much complexity even to simple tasks that I wonder why the management don't see this issue.

[@danwilson5630]

Thanks

[@wajideus4591]

@9:00 - Personally, I hate libraries. Not because I think all libraries are crap, but because: 1. I like knowing the full scope of any problem I'm working on, and when you do know the scope, you realize that the library often gets in your way much more than it helps you. E.g. modern OpenGL takes ~400 SLOC to get a triangle on the screen and vulkan takes ~1000. Yet, you can write a triangle/convex polygon rasterizer in ~10 SLOC by using 2D matrix determinants to do inside-outside testing. Toss in some simple trigonometry and with the same 400 SLOC, I can write a fricken fully software-rendered first-person shooter in ~2 hours. How are you helping me again? 2. Libraries are never *done*. They bloat indefinitely, adding more and more features that no one wanted or asked for, and occasionally doing subtle API changes that completely break my software. Which means that I have to actively expend time and energy in maintaining all of my software. You're creating more work for me. Stop it. 3. Object oriented programming. My god. Entire generations of programmers who've never written an allocator or used a profiler once in their life complaining about manual memory management; meanwhile they're creating managers, factories, requests, components, and a million "doer" objects that shuffle around massive amounts of hidden state; turning things that I would do in a handful of lines of code with simple callbacks/higher ordered functions and structs into something that's 3400 SLOC of code split into 4 class files. Just...stop...please...You're overengineering things. I could name a few more problems (specifically things like DLLS and wrappers) but these are the biggest ones.

[@seidenada526]

Ohh the 3rd point, my favorite rant. Not only bloated OOP with lots of doer classes, but bloated code in general. I'm right now working on an inherited front-end app that is so overengineered that its easy to get lost. So many similar functions laying around, walls of forEach instead of a simple map, and many more unnecessary bloat. And I also agree with minimizing library use, but go figure why in JS world people are importing libraries that only implement a 5 line function!

[@dmstrat]

I have come across this type of scenario regularly. Sometimes it is just an architect talking about our current software as if it already had that new architecture in place talking about how amazing doing it that way works over our old approaches. That's just frustrating as they know we aren't using that approach as if talking as if it is there makes the developers want to start using it, but we don't have time to train everyone on the new architecture and the one acting like we're already doing it won't provide that first conversion sample and document it for others to follow.

[@ThoughtinFlight]

This is how I feel about Elixer. Erlang is perfect. Why was it made. I may be wrong but I feel a lot of new languages are like this. The next actual innovation in coding will be VR sequence and flow diagram coding. Not another typing symbol language

[@sunwukong6917]

This channel is just what I needed.

[@stephenmorris297]

I agree totally. In the C# and Entity Framework world there are a lot of people implementing the Unit of Work pattern on top of the DbContext. What they don't understand is that the DbContext IS A UoW, just using implicit transactions. There are times when it can get more complicated but that is generally due to a poorly architected system. For every project I've ever worked on, the implicit UoW, used in conjunction with a simple repository pattern is all that's needed. But I've seen many complicated and convoluted implementations of the unnecessary UoW pattern. Very sad.

[@HealthyDev]

You have no idea, I literally am dealing with that on my current morning gig (not the first time)...great example

[@mamertvonn]

dem this needs more views

[@MagicJohnston777]

This my gripe even with the software tools being made more and more complex. The IT profession started with, all you needed to know was COBOL and the mainframe, or BASIC and the PC. Now you need to know multiple programming languages with complex syntax, templates, libraries, IDE's, databases, operating systems! There is disconnect between what IT engineers develop for the development environment, and what companies owners and managers need. Companies owners and managers want RAPID APPLICATION DEVELOPMENT. When they market and promise a solution to their clients, they want the system and reports delivered like the next day! It is like swatting flies with sledgehammers, or working with tools complex enough to design a space shuttle, when managers just want an old delivery truck to travel A to B. A company was quoted $30,000 by a vendor for an APP which would take a couple of months to design. I impressed management by designing a solution for them in a few days in Microsoft Excel, and since they all had accounting backgrounds, they loved Excel. All they wanted was to view some simple data lists in Pivot tables and fancy charts. It did not need a complex coding solution!

[@HealthyDev]

Yes while I am all for innovation knowing the most cost effective and valuable way to meet a customer’s needs takes a lot of experience. I think you’ve demonstrated a great example.

[@smilebot484]

this is bang on. last project the cto was driving all these crazy latest coolest thing just because. they did not solve sny problem we were having. eg. graphql. in the end the money dried up and the business wasn't able to solve problems fast clients really needed. this problem is so huge in software generally. it's so easy personally to get into this mind set. great video.

[@sasukesarutobi3862]

I've heard it said that the difference between a junior developer and a senior developer is that a junior developer tries to write code that only a senior developer could understand, but a senior developer writes code that even a junior developer could understand.

[@mastadutch117]

I made a very bold architectural choice when choosing Webflux for a project, and have often asked myself if I fell into the "new framework hype." There was a steep learning curve for new devs onboarded onto the team. But ultimately, our app was extremely I/O intensive on very large enterprise datasets, and we had kafka data we needed to stream into the application as well. So it was the right choice in our scenario. There definitely needs to be a balance, in the sense that sometimes that new technology IS the right choice. Leaving your comfort zone IS OK, but only when you do it for the project, and not for yourself.

[@HealthyDev]

Makes sense to me!

[@iliyaisd]

So freaking true. I'm so sick of this happening all over and over again, perfectly working battleproof languages and techs getting cancelled "just because", and replaced by poorly tested bloatware.

[@erikgook598]

This is so spot on. However I'm thinking there is another side to it. To some extent intellectual masturbation is not necessarily a bad thing, it has it's place. We should find some kind of outlet for it. Companies should set aside time for it so people can indulge without it leading to the bad effects described in this video. Lab-days, small demos proof of concepts. Make room for playing with ourselves (or at least our own intellects) in the workplace!

[@HealthyDev]

While I completely support this, I’ve been on projects at more than one company that offered time to work on your own stuff and demo days and it still didn’t stop some people (I’m pointing to myself in the past here too). Something about engineering seems to breed this in us, and without more experienced engineers around to tell us when we are, it feels like it’s a problem. Of course that’s just my opinion. Once I became an architect in my early 20s the pool of mentors I had shrunk dramatically and politics became more prevalent than collaboration, so I’m sure that had an element to my perspective. What are your thoughts on that? I guess you’re thinking it’s less common of a problem?

[@aev6075]

Smart understand complex things. Genius can make complex things simple.

[@aliensarefromspace]

I hear you. i can relate to almost everything you said, but i have to disagree a little bit, under the conditional that sometimes more advanced things need to be done to achieve the proper long term outcome. And people shouldn't be afraid to use advanced topics like messages & ques where they are needed. KISS, but not too simple so it would hurt you in 3-6 months. :)

[@HealthyDev]

Absolutely. I’m not always the best communicator but I was trying to advocate for picking the right tool and being careful not to over complicate things. But I’m all for learning new stuff (given it fits the use case)!!

[@BrownRicePaddy]

Ngl, I am entry level programmer. I've come to a point in my life where I am really concerned over what to do in the future, and I have considered majoring in CS and starting a career as a software dev. I'm the type that can tend to worry too far into the future. And so I watch these videos to get an understanding for what sorts of problems programmers get into and sort of get a feel for what to expect. I can infer some meanings with context and what little knowledge I have on the topic, but sometimes I get the feeling that I am simply too inexperienced to even be able to properly understand the concepts you explain. I feel somewhat out of place, as I'd imagine most viewers here are somewhat experienced in the industry. Would you advise against this approach to feeling out the industry? Am I putting the cart ahead of the horse?

[@HealthyDev]

Hey there. My content is skewed towards people with experience, but I know people feeling out the industry have said they get stuff out of it too. I would try not to worry if you don’t understand it all. It takes time and experience to run up against some of the things I talk about.

[@daniellister4701]

I did what most people did when I started, JavaScript and its associative libraries. You just get lost and dont understand what your trying to achieve as a newbie. I switched to C# around a year ago. I am much happier. Also focusing on Design Principles and Software Engineering Principles, not languages, means I can now write code and understand whats going on.

[@HealthyDev]

Nice. 👍 I agree the JavaScript ecosystem has become way too complex for many applications. React and the like are great for apps that truly have teams per component and big scaling challenges (like Facebook where it comes from) but I’m seeing it used in many projects where it’s an enormous strain to productivity.

[@akivaliaho5166]

@@HealthyDev this boils down to the programmer ego question once again. If the intelligent guys at Facebook are doing it my small startup also has to do it to look cool. There's one problem: your startup has 3 guys programming. Facebook has an enormous engineering team. You'll never have enough time to fully understand the complexity of certain technologies if you are constantly juggling too many hats. It's time to put an end to a.) adding too much unnecessary complexity to a project because you want to look good or b.) start to add more people to focus on certain aspects of the stack if you really have problems of that scale. Unfortunately some of the more dedicated guys can nearly pull of managing this crazy complexity so it shifts the thinking a little bit: instead of trying to make it easier people are competing on who can understand most complexity. Wanna swat a fly? Don't shoot it with a damn machine gun.

[@HealthyDev]

@@akivaliaho5166 I couldn't agree more.

[@Hannodb1961]

12:00 "Just to do a hello world, you need to learn 12 new concepts". I see you've met angular. 😄

[@BlackBlade]

I am honestly there, and overall always worried about this Where I am at the code is pretty bad? lots of reparative code, not docs and so on And I did start making my own library as the existing once cost, and I seem to find doing it is easy over all and only need a small part of the entire library that is offered And honestly always asking my self "Is this the right choice?" I am working to transform the company as much as I can, hopping it will help it to be easier and better for them to update later I do try to comment it and hopping in the end to release the library open source for outers that may need it without spending too much for it

[@HealthyDev]

Makes sense to me. I think open source is great and of course we need to keep innovating as an industry. I just feel it’s an area where we can fall into poor choices if we aren’t pragmatic about it. It sounds like you are! 👍

[@BlackBlade]

@@HealthyDev That dose relax some what, just when you discribe it was really like mm.. check check check 😅 Thanks for the reply

[@radekcrlik5060]

Amen. New frameworks and libraries are deprecated and new created faster than anybody needs them. I love how this is still valid today :D

[@ranska2506]

minute 12:00 so true.

[@niwadev]

If you can't debug it anymore it's too complex ^^ We're using also attributes, decorators and so on. My experience after a version migration of the .NET core framework: it can take you a bunch of time to find some issues. For example: some of our models had validation attributes and they didn't work like in the previous version. As we started debugging we only recognized that the controller wasn't called. After days of research we found out, that the validation attributes rejected the model we'd given to our api.

[@HealthyDev]

Yep, that's a great real world example. Thanks for sharing.

[@twistedbydsign99]

Most the disdain I see on projects is because people don't want to read they want to write. They most likely aren't good at understand code, very few are. What I do when I join a team is I don't try to reinvent anything or turn over any tables. I try to work with the mess that is there for a LONG time, because it takes a long time to find the actual issues, not just the knee jerk ones (you defined a variable mid way down the class not at the top oooooo). If you join a team the most profitable thing you can do is "hey guys you see this code right here? I found out its dead code and we can delete this whole class."

[@HealthyDev]

Great point. I’m totally with you here. Reading existing code takes longer to get up and running, but not as long as rewriting! Somehow we convince ourselves that isn’t true when we get impatient. Glad to hear you see through that lie...

[@Hato1992]

Uncle Bob writes about it in his blog, he call it "Churn". As a man who started his carrier in early days of programmin,g he saw many languages. And in his opinion, last language that provided something new was made in 90'. Any later language is just the same language, but with a bit different flavor. Also "war" between strong type and no type languages. Every few years new "better" language come and is trendy. New developers think that language make things easier, but that's not true at this point, it was in assembler era, but not now. It's all about work ethics, using design patterns, tests etc. When I see my code from few years back, I'm thinking what kind of idiot wrote that. Back then I had this stupid pride that I can understand hard code, but it was a lie. Now I try to write as simple as possible, sometimes I make function that have 1 or 2 lines of code, but it required for readability of code.

[@cyberneticbutterfly8506]

Good frameworks or libraries are signified by solving something significant. Solving something trivial isn't worth it. E.g. Node giving a good non-blocking benefit. E.g. Babel converting ECMAScript 2015+ to backwards compatible code for compatibility with the various browsers, instead of having to write your JavaScript in a way that it somehow works on all browser versions. These are fundamentally significant benefits. If your project or company don't need the exact benefit that separates, say, C# from Java, then in switching language you are adding extra time to the project for no reason.

[@edwardmitchell6581]

I remember, in 2013, when we moved to .NET MVC for a simple web app, we sat through a discussion on dependency injection. To this day, I have no idea what dependency injection is or the benefits. I have a 135 IQ. Incompletely lost interest in Software Development after that. With my data background, I had no idea why synching drop downs menus to database values had to be so hard.

[@marna_li]

I want to use the latest, let's say .NET. I want to be able to make a difference by bringing a new perspective in software development methodologies based on my experiences. I see a lot of good programmers just write code without thinking about the domain, and then not even design the system. Being too technical in our thinking is a challenge, and even so when we are divided into Front-end and Back-end developers. Then it is even harder to reason about and to focus on the vision for the product that we are developing.

[@KilgoreTroutAsf]

3:20 Those were the dark ages. Now it takes 100 lines of code to write the StringAbstractFactoryDelegatorManager class that manages every possible case of creating a string by having to specify WHY you need it to exist. Progress.

[@ian1352]

It's hiring practices. Look at the questions you get asked in an interview. You need this stuff on your resume to get employed. They'll look at you like you're deficient if you're not constantly learning new frameworks and languages, instead of say practising one. I don't get better at playing bass guitar by dabbling in a bunch of other instruments. But that is exactly what the software industry demands. It's a vicious circle. To address the C# example and why it is what typically happens. It begins with various employers starting to demand some new programming language. There'll still be lots of C# jobs around, so those with the skills will mostly stay with C#. But over time the other language(s) will grow and more people will jump ship. The market for C# over time either does or appears to shrink causing more people to move to what appear to be the more popular languages. Then when you need a C# programmer you can't find one.

[@stanleyshannon4408]

I have been in this industry longer than anyone I know, and I have to say I have problems with this advice. 20 years ago I was a highly competent C++/MFC programmer with nearly 10 years experience using that technology. I looked into C#/.Net and immediately invested the time in learning it because it was clearly a better way to do things. In about 2006 I learned Javascript not because I wanted to but because it solved a problem. A few years ago I began learning typescript and both Angular and React, and I am now learning Vue - because these are important technologies that actually make me better at my job. Developers have to continue to learn and integrate new technologies into their skill set, it is simply part of the occupation, or you can become quickly obsolete.

[@HealthyDev]

I think your career decisions are excellent. I’m talking more about the fact that there are now hundreds of single page application frameworks on GitHub, not that SPAs aren’t necessary (as an example). There’s a difference in my opinion between necessary innovation and wanting to “roll your own” with problems that have been solved ad nauseum by the community already because you think some small aspect of the syntax could be better without adding any value. Not sure if that helps explain my stance any better, or even makes sense? 🤷‍♂️

[@xybersurfer]

i used to do this when i was still learning to program. but now i hate overly complicated code. i take pride in the readability of my code. it usually doesn't look right to me until it is readable. people not thinking critically, about why they are adopting all these new frameworks is indeed a problem

[@ManuelBTC21]

12:30 Be very wary of the "get stuff done" mentality. It promotes short term thinking and piling on of technical debt. This is an especially risky issue with contractors who may not be around long enough to see the explosion of what they hacked together.

[@HealthyDev]

Sure I understand where you’re coming from. While I’ve seen that too, I believe our industry suffers more often from unnecessary over engineering than under engineering. There’s a balance. This video is trying to speak against perfectionism and complexity that prevents the business from reaching their outcomes. That doesn’t have to be mutually exclusive with maintainability. YMMV

[@MooseBme]

He speaks gospel truth!

[@KilgoreTroutAsf]

Taking pride over how many languages and technologies you know as a developer is a bit like taking pride on how many pencils and brushes you can use as an artist. Who cares. Can you write a login system? A process manager? A graphics library? A videogame? A physics simulation? Multithreaded code? Those are the actual questions. Any experienced programmer can learn a new language or a library in a few days or weeks if the project requires it. The work of a software developer is solving abstract problems, not how to write a "hello world" in 20 different ways.

[@HealthyDev]

Agree 100%

[@bawbak8800]

One of the reason of that is because anyone has his/her own definition of simplicity. When we say something is simple, it means based on our background (which we're not aware of that) it is easier for us to understand and we assume if something is easy for me to understand, it must be easy for others too, unless they are STUPID and don't understand anything.

[@armanrozika]

it is sooooooooo true

[@michdem100]

Let me think - the things in my company that I'm most proud of: 1) A module (~5k of lines with tests) that has about 3-5 public methods 2) General boilerplate reduction Hmmm I might not be making it harder I think

[@JoelChristophel]

Thank you :)

[@guatagel2454]

I love programming. I hate frameworks. Every time I use a framework, there is some detail, some corner that the framework does not cover. Then you have to tweak here and there. Absolute hell.

[@Igneous01]

I think about it like this - how many words have I written/typed over the last 15 years of my life via text, forum post, reddit, etc? Do I have the same pride and ego about those things? No I don't. I see the words as a means for communication at that specific point in time, and nothing more. I don't attach my sense of self to it. It's as temporal as this comment I'm writing right now. I see code in the same way. It's work that was done at that specific point in time for that specific purpose in mind. It may not exist in the future. That's totally fine. I accept that the things I do are impermanent and that they don't define who I am as a person. I've learned that this ego in our work is when we try to attach our sense of self to our work. We base our image of ourselves on what we write as code. We identify so strongly with it that we get defensive to criticisms, sharing, and communicating, because we feel our sense of self is being threatened. It's one of the most toxic and self-limiting beliefs we can take on about ourselves. We are more than the code we write.

[@HealthyDev]

Your attitude and insights are great. Thanks for sharing, I can't agree more.

[@matemolnar5879]

I completely agree with every aspects of this video. However, i never expected to happen to me, but i’m contributing to a heavily “under-architected” project. Managers, leads and architects are obsessed with making things simple. That’s fine. But in reality, it means repeating the same antipatterns for a decade. No change is allowed, even if there is a much simpler, quasi industry standard alternative. Worth mentioning the project is funded by governments… I’m not sure this kind of frustration is typical or not.

[@guseynismayylov1945]

There is literally 0 positions for vanilla js. I would be so happy if someone used just vanilla js or minimal template framework like EHTML. This is the reason why I do backend stuff primarily, simply because backend frameworks are not fucked as much, but still painful… I think starting from jQuery number of positions for vanilla started to decline and now it’s just really nothing.

[@valcrist7428]

What sucks is you're a senior programmer who has tons of experience.. then is will be nulled just because there's this new programming language. Then you are asked like a fresh grad from an interview.. like what is the "syntax of this?"..

[@FlaviusAspra]

The problem is not using frameworks or libraries. It's vendor lock-in. Wrap the framework in a plugin! Make an adapter for that pesky library! Sure, you'll have just one implementation NOW, but you'll be able to swap it out. And it's not a whole lot of work doing this.

[@blackerhawk1508]

Well, this makes me feel better for not developing websites with every feature and complying every acceptance criteria made with custom code, and then just using a CMS with carefully selected plugins, hardening, and just the neccesary custom code. I think our code producton effort is way too valuable to waste it reinventing the weel. There are a lot of other much more valuable things we could code from scratch, for example, a pollished UI customization, UX enhancements, custom business logic, or anything that's putting the business, the quality of the product, or some process optimization in advantage.

[@Torterra_ghahhyhiHd]

strategic vs tactical the need of the project and the busyness not the same need of the developers.some time it depends. some times project just need to be tactical. then the busyness wont prevail over 10 years. esporadical flow of some kind o busyness by nature my only need tactical not strategical.

[@jason_v12345]

There are valid reasons to write complex code (beyond simply abstracting methods to reduce LOC). Good code is like good writing: it achieves more with less. For the same reason that I wouldn't insist that a person rewrite a PhD thesis at a second-grade reading level, I think some developers just need to level up. You don't like "complex code"? Well, I don't like having to deal with verbose and brittle code just so that you don't have to learn.

[@Hannodb1961]

Nobody want to work on C#??? I fricken LOVE C#. Its the most elegant, most powerful, most well defined language I ever worked with, and if I had my way, I wouldnt want to work on anything else. I dont want to spend my time learning new languages and frameworks, I want to be proficient with the tools I have so I can focus on _what_ I need to do, rather than _how_ I need to do it. Yes, it might be boring at times, but it also allows you to do some really cool things because you know the ins and outs of that language. I dont want to be a "jack of all trades, and master of none"

[@HealthyDev]

I still do quite a bit of c# today. I was describing a sentiment I saw in the market in Austin, not that I necessarily share the same. Use what works best for you to get results!

[@Hannodb1961]

@@HealthyDev Sure. I hope that trend never blow over to my country. I will moarn C#s passing

[@AussieAmigan]

If you've used C# as I have in a plethora of different architectures and MS frameworks over the last 25 years as I have you probably have become a "jack of all trades, and master of none" just as I have.

[@brandonpearman9218]

Fully agree. but unfortunately, normally nobody ever notices when a tech lead or architect makes a solution overly complex. 1. often managers trust tech leads /architects (especially if they use a lot of jargon all the time) 2. developers feel inadequate when working with a complex solution and strive to learn the patterns and tech put forward by their lead, instead of questioning the need for it (nobody wants to argue with their boss anyway). #KISS #YAGNI #agile #iterative

[@HealthyDev]

Absolutely. I hope more leads learn to be more transparent with their team and adapt things like yagni over their career. It sure benefits the team to be more pragmatic!

[@harehnkaundun1406]

One thing I really disliked hearing about from people who only know superficial knowledge about coding is that once you know one language, you know all of them...

[@llSoleyll]

I agree on most points but 12:30-13:10 is very misleading as it puts the emphasis on putting out as many features in as little time as possible to get recognition from management and thus more money. The main issue I have with this statement is that management sees it the same way and you have to compromise overall codebase quality for feature rate, recognition and money, because there is no immediate value for the company to really refactor a whole component to implement a feature, if a small dirty workaround would also have done it aswell and you then have to justify why developing a small feature took you a whole week while dev B has put out a similar feature in 1 day. I'm fine with the statement in regards to exotic features and frameworks, which actually hinder your productivity, but just telling developers that they should aim to deliver as fast as possible for more recognition is basically telling them to write quick and dirty code, instead of long term maintainable code, which is obviously harder to design and takes more time to write.

[@HealthyDev]

I hear what you’re saying. But (and I may have totally failed at this) while my intention with this video is to encourage people to focus on business value, that doesn’t have to be mutually exclusive with high quality. You can write great software, that produces a lot of business value, but makes smart decisions about not being over engineered. It’s possible but takes some nuance and intention. Not sure if that clarifies it for you or is just more confusing lol!! 🤣

[@llSoleyll]

​@@HealthyDev Thanks for the clarification, I was pretty sure that this wasn't the message you were trying to bring across in your video and that's why I just said that it is "misleading" (not "wrong") as some devs might interpret it as justification for quick and dirty code but no sane software developer who worked many years in the industry like you did would ever suggest something like this for some short term benefit. I have worked for many years on a pretty old (>25y) legacy code base and there it was pretty much a mutually exclusive decision to deliver high quality code (which always meant multiple refactorings) or just quickly deliver some feature, which could be done without any refactoring, but heavily impacting code readability, maintainability and thus future productivity. But you also said to produce "business value" (not just "features") so to me a well structured and maintainable code base has a lot of (long term) business value and then we are completely on the same page 🙂 It is just more difficult for management to spot and to measure your performance based on how well you keep your code base clean as I know of no way to measure this.

[@HealthyDev]

@@llSoleyll sounds like a very reasoned and realistic mindset given the situation. Much of the work I do is never appreciated, I just do it because it has to be done!

[@BernhardErnst]

Not every programmer is aware of all of the existing plugins and libraries. This makes programmers use different libraries than other people. These days there are just too many frameworks and standards. Some frameworks add too many layers of abstraction which makes adding something new quite time consuming.

[@oliver-church]

There is so many really awful frameworks out there :) There's also some good ones, but sometimes rolling your own custom solution is way easier than using a wonky framework that is very convoluted. One not well kept secret is a lot of indy game devs just use socket IO for their back end server with completely custom code, not one of these fancy gameserver frameworks. What convinced me to get out of a career as a 'software engineer' was one of the senior guys making it look like I need to spend years on his specific language (NodeJS in this case) to be considered valuable. Reality is anyone can learn a programming language, programmers are going to become less valuable, as a field it will become more competitive as time goes on. Kind of like how a car mechanic is considered a standard job these days.

[@HealthyDev]

You bring up an important point here that to be successful today you don’t need mastery over a language or framework. With that being said, if you’re making architectural decisions that impact many people, I’ve seen a lot of over complication and custom stuff used that didn’t add value. Having done this type of work for a long time, I don’t always get it right. Thanks for sharing! I like your example of low level back ends in gaming.

[@neocephalon]

Programming, like Math, and any other subject can get hard. There's nothing wrong with programming getting hard. It can be a good thing. However, we should strive to make for simplicity over time just as with how problems are solved in other fields. This will make projects easier over time.