It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
My anecdata, people who overly focus on language and tools tend to be the worse developers. It's the developers that effectively address the universal problems of writing software people want to use, like api usability, reliability, data consistency, maintainability that have the most props in my book. The best developers I've known weren't particularly attached to any editor, language, or framework.
> It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
I think this is an apt analogy. Mostly because carpenters who use hand tools produce more beautiful, unique works of art. When everything you do is on rails (no pun intended) you don't have the flexibility or creativity to make works of art. It's like saying Ikea tables (the equivalent of an idiot proof language) are just as nice to look at and functional as a purpose-driven hand crafted table. I have my doubts, despite using Ikea when I "just need something done".
Nice one, being it elucidates the art being lost in other fields (and perhaps all over).
Your analogy doesn't make sense. There's nothing about the programming languages you consider "least common denominator" that lock you into a specific design, unlike your Ikea table. Actually those LCD programming languages are generally the least opinionated in how you use them.
> It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
Serious question: all else equal and without any additional information, between two carpenters who produced the same output in the same time, one with power tools the other without, is there any reason whatsoever to assume one of them is any better than the other?
No, drilling holes doesn't make you a good carpenter, use the most convenient tool you have available. Designing a good chair that people want to sit in then producing it from idea to reality does.
I'd think manual carpenter is going to have to retire early due to repetitive strain injury.
Same but for a different reason. Being able to overcome the learning curve and become comfortable using power tools to achieve equivalent results makes you a valuable employee as a human, it raises you to a higher level of control and increases your capabilities beyond what you could do with bare hands. (The only benefit of being capable without power tools is if there's no electricity for example. IANAC)
The same with "easy"/mainstream languages: something like OCaml/Haskell/Nim/Nix/etc. is a power tool with a steeper learning curve compared to something like Python/JavaScript/shell scripting; you being able (and willing) to handle it without abundance of learning resources says something about your mental capacity and potential value as an employee.
This is like one (non tech) company that I was hired at as a dev lead where they were about to embark on writing an “address validation module”. I quickly put an end to the entire project and worked with a vendor to license CASS software.
Companies pay employees to add business value. Not to get into their own flights of fancy to do things the hard way. As you mature, you learn only to focus on things that “make the beer taste better”.
I have yet to see an argument by any of the proponents of “obscure” languages where their choice adds business value.
And the “hard problems” that are being solved by the large companies at a scale that has never been solved are doing so by using mainstream languages.
I’ve never seen a report of a job interview where they asked you to reverse a binary tree in Erlang.
The vast majority of problems that developers are being asked to solve are not that hard technically. They are business problems.
I mean more having learned to be productive in an obscure language as a positive marker regarding your mental capacity, intrinsic motivation, autonomy and initiative. If you then insist on using it for everything, business value be damned, that is a red flag. Choosing an obscure language to tickle your fancy would be negative value to me as a business owner since I need to hire and maintain a team of developers who are all comfortable and proficient in it. However, there are circumstances in which an obscure language might just be the right tool for the job (and overall architecture that can accommodate a small cohesive component written in a different language has its benefits).
You think it’s a red flag for a business to hire people who can add business value?
I’m motivated to get up everyday for the same reason most people are - money.
I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you? Out of all the millions of things I can do and have done in my free time over my career (including a working hobby as a part time fitness instructor back in my younger days an avid runner and a weightlifter) spending more time sitting at a computer outside of work isn’t one of them.
And the obscure language would hardly ever outweigh the need to recruit developers easily.
> You think it’s a red flag for a business to hire people who can add business value?
Where have you seen that?
> I’m motivated to get up everyday for the same reason most people are - money.
You are quite mistaken. Once they have enough to exist comfortably, people tend to seek meaning not money. The emergence of OSS ecosystem is the best example -- a lot of it, including the most popular OS in the world, came about as hobby projects people did in their spare time. If you're a software engineer, I bet you use products of their passion a lot in your money-making activities.
> I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you?
Again, all else equal, if I need to make a decision as to who would be a better, more capable employee in absence of other information, the one who managed to be productive in an obscure language would be higher on my list. Just that. Everything else, making people work overtime, etc., is your addition.
My question was not answered. In that scenario you have access to the work both of them do, so it speaks for itself, and it is equivalent work done in equivalent time. Use or non-use of power tools is the only difference. Do you factor that in your judgement or you flip a coin when choosing an employee or supplier?
Okay, so this means it's not relevant to you which is... an interesting take. I guess you better operate your business in at-will employment legal landscape (and not feel bad for your employees' families after you fire them left and right this way).
For me I would definitely make use of this extra information before hiring. Hiring a carpenter who's able to work with power tools is likely better, unless I need to foresee a situation where they must work without electricity. Even if they are physically fit, power tools can enable a human to do something not possible at all with bare hands.
For a programmer it's the reverse, if we assume "power tool" is an "easy" language compared to something like OCaml, or maybe tools like VS Code and Copilot compared to vim. These tools don't help overcome a physical limitation, like the power tools of a carpenter, but a mental one. Being able to set up vim fully to be as productive and produce as few bugs as someone with VS Code, or being able to pick up Haskell without being able to immediately get a human answer your every question, exemplifies the type of higher-level skills and learning capability that is the primary value of a human employee compared to a robot.
In other words, in context of this discussion, the equivalent of carpenter's power tools might be much closer to Haskell + bespoke vim/tmux setup than JavaScript + VSC.
My anecdata, people who overly focus on language and tools tend to be the worse developers. It's the developers that effectively address the universal problems of writing software people want to use, like api usability, reliability, data consistency, maintainability that have the most props in my book. The best developers I've known weren't particularly attached to any editor, language, or framework.