What is a developer supposed to do? Should you use MVC, MVVM, SOA or another architecture? C#, Java, or one of a thousands of other languages? Agile, Scrum, or waterfall methodology? The decisions that developers have to make seem endless: architecture, platform, language, repositories, methodology, framework... and so on.

Although I'm just a proud hobbyist and not a professional developer, it is the discipline of business that provides an answer to the conundrum of choice. I'll start with the Zen answer of, "having an answer is the same as not having an answer, so we'll call it an answer." What does that mean? It means that the answer is worthless. How can an answer be worthless? Consider this: do you really care about someone's opinion regarding the age-old Emacs vs. Vim debate? No, of course not, and now you clearly see how some answers (such as "use this over that!") are absolutely worthless.

Let's say that you feel inadequately prepared for a development task, so you seek out a mentor. While this is a wonderful step to take, you've already overlooked the fact that you may be incorrect regarding your supposed inadequacy. You've taken a bold step to put your faith in another (more?) experienced individual, but do you need to and will their experience, no matter how grand, offer any actual value? With mentors, often there is value to be had, but not always.

Assume that your newfound mentor reviews your work and sees that you plan to address a client's web app needs utilizing straight-up PHP. Your mentor protests and belittles the capability of PHP. We've all had something like this happen, right? Of course! How you respond to the mentor's influence is very important in these situations. Why does the mentor view PHP as unsuited? Many of the largest (and arguably most "powerful") sites on the Internet use PHP, so is there a specific limitation that impacts your client's particular needs? Maybe. The more likely explanation, however, is a volume of biased opinion from the mentor.

Maybe she had a bad experience with the language, maybe she follows the clique-like nature of programming culture, or maybe she only had cereal for breakfast instead of the bacon she wanted. In short, even the most sage advice you'll ever receive can also be warped with complete and utter opinionated garbage based upon incalculable assumptions, pride points, and misunderstandings. In fact, as an educator, I've caught myself mid-sentence giving bad advice. Why? I don't know. But not all mentors are educators and know well enough to stop, retract a statement, and admit it to be utter garbage. Most mentors will double down simply to save face.

The answer to, "What should I use to solve for x?" is simple! Here it is: use what works.

Does your solution work? If yes, proceed. Is your solution the most computationally efficient? Probably not. This is an inherent truth, not a failing on your part. Is computing efficiency your actual concern and likely to be a real impediment to progress or is it an ideal expectation of what ought to be? Ideal be damned. The same goes for cost, deployment time, maintenance requirements, and even the selections you make related to infrastructure and platform. If you don't believe that any and all of these inputs can cause bad output, try an experiment. Base all decisions for your client over the next week on cost alone and see how horribly your project, and reputation, have faltered. It won't be pretty.

As someone who has spent at least some portion of his career using spreadsheets (of all things!) to build apps that mimic standalone applications, I can tell you that nobody outside of the programming language cliques gives a damn whether you wrote a program in JavaScript on Linux, C# on Windows, or in Objective C on macOS. Companies actively request that I work with them to streamline their workflow using Excel spreadsheets and some VBA macros. I happily comply... if that is a solution that will work. Again, ideal be damned.

If you want to improve yourself and hone your skill-set to seek technical perfection, that's wonderful, but don't "take it out" so to speak, on your client. Select the right tool for the job from your existing toolbox, or the closest hardware store. In the time it would take you to travel to identify and buy the most perfectly crafted hammer, someone else will have used the most rudimentary of hammering tools to quite effectively drive thousands of nails.