Today I was looking at a "new" development "tool" called Svelte. While reading about it I came across this response to a blog post:
The fact that you have even heard of Haskell, let alone wrote a "hello world" in it, sets you apart from the majority of JS developers out there (probably 99%, quite literally). So it does not surprise me that it was reasonably easy for you to pick up Elm (and appreciate its qualities). You are probably smarter, more open-minded and flexible than the vast majority of people doing JS work. And it is precisely the point you were making when you said "subjective".
The reason why you found so much bad code in the past 8 years is because most people just suck at our craft, and often just do not care (corollary of the above). They are not going to make better code in Elm.
At ZimBaroo's Geeks (ZG), we spend a lot of time on the fundamentals of good code and understanding why we do what we do. Having said that, I would like to use the above quote to expand on why we the "Geeks" of ZimBaroo's strive to understand the fundamentals and why we are programming a solution a specific way.
First let me just give a bit of background on me. I have programed in both Haskel (slightly more than a hello world) and Lisp. I have actually written production level code in Lisp back in the late 80's I have programmed professionally in 10 languages that I can think of right off the top of my head. I guess if you have been hired or started in your programming career since 2000 it may be easier to pick a language and stick with it. However, that has not been my life experience.
I really just started in Angular/Typescript world a year back. I found it fairly easy to pick up the basics once I accepted the mind set of things being asynchronous in nature not synchronous as in most other programming worlds. I have found that moving from one language to another and one technology to another is not that difficult if you understand the fundamentals of programming and technology. That's why at ZimBaroo's we spend a lot of time talking about what we are coding, how we are coding it, and why we chose to do it a specific way. At the end of the day, when we have to switch to a new language/technology, I want my team to be able to move quickly.
I agree that a lot of the programming world is made up from "web-hipsters and brogrammers" regardless of degree or no degree. I happen to have a degree in Computer Science. However, I have met too many programmers with degrees that don't know anything and too many without a degree that know a lot to count a degree as having much value.
I also agree that the technology you use to solve a problem can matter, however a lot of the technology choice is "subjective". Should I use a Microsoft Stack or a LAMP stack? I can strongly justify both having built large scale production solutions in both. Saying one is objectively better than another is really some dude/dudette knowing what they like and then justifying why it's the best solution. Given the projects we at ZG are building currently, I could build them in Java/Swift or NativeScript or Ionic or ...
In reality this is all subjective. Anyone who tells you otherwise is (in my opinion) lying or confused. Yes, I might be able to do a cost comparison on the hosting and long time run costs, but I have justified too many ROI's in my life to believe any of that. Looking into the future is full of assumptions and unknowns. Want real objective answer? Run them side by side for a few years, send 50% of traffic to one solution 50% to the other and see where you land after a few years. Tracking all your maintenance costs, upgrade costs, etc.
As for client side the same thing applies. Tell me this tech is way better than that one, give me a list of reasons why, and I will just think you are an evangelist for the tech you just quoted me. I most likely would ask you some questions; maybe try to drill into your assumptions, but at the end of the day I would let you have your conclusion. However, I most likely would not adopt it based on just your list of reasons.
At ZG we have a saying "Pick your poison". Because no matter what solution you pick, it is going to have positives and negatives. At some point in the future, you are going to end up having to deal with the drawbacks (negatives) of your chosen solution. Hence you will have to drink your poison.
I strongly agree "most people just suck at our craft". Some of that is because not everyone that codes should be doing coding. But a lot of it is because I don't think they have ever had to "drink their poison". One of the first major systems I ever worked on ended up being in live production for 15 years. During that time I was the soul support of the system. I worked at several different companies during that span and continued as contract support for this system. I hardly ever worked on it, because thought went into the building of it. I figured at the time I was building it, I would work for that company forever, and knew they would call on me for support if the front end team could not handle it. I was too lazy to want to have to support it, so a lot of thought and refactoring went into the code so I would never have to touch it again. But also a lot of thought went into the code so if I did have to touch the code it would be easy to maintain/upgrade/change. The system was built in C with a CISAM backend.
I think with most guys now, they haven't carried code long enough to have to learn what it takes to build good code, so they just build a lot of code. They build a project, get it into production, move to another company for pay boost or whatever reason. Then rinse repeat. Maybe they pick up a project someone else wrote and they are supposed to modify it, but then they end up just re-writing the whole thing because they can't understand what is there. I have seen both of these play out again and again.
That's the reason at ZG we have at least one code review a week. At anytime anyone is allowed to look at anybody else's code and ask why they did what they did. At anytime anyone is allowed to refactor their code to make it cleaner and better. We have some basic rules that help us form better code and we discuss those a lot. Because good code and fundamentals matter.