[ekianjo]

I think you misunderstand the parent. The obsession to always focus on tools is I think, what they described. In the end of the day what matters is what you produce, not what tools you used. Nobody cares about what you used, apart from engineers.

[nojvek]

It’s not mutually exclusive. We are craftsmen and craftswomen. Definitely obsess over the problem but also obsess over the tools used to carve out the most usable elegant and efficient solution.

It’s really asking the same questions over and over again. Can we do better ? Does this tool allow me to be efficient, write safer and faster code, how good is the adjacent libraries and ecosystem ? What other kinds of things does it make it possible to solve?

[naniwaduni]

You care.

[toss1]

Are you coding as a hobby or a profession?

If you are a professional, you will use the most effective tool for the job - to get results. What tool will produce the best results - schedule, budget, quality, maintainability, scalabi, portability, etc.?

Other than outliers that will crush your productivity, or multiply it, your feelings are pretty irrelevant.

Similarly, when you get into a racecar, your feelings about your preferred driving style are irrelevant - if you can change the setup to accommodate your style without slowing jt down, great = but if not, your job is to adapt to the situation and reliably get the best possible result.

Either way, you have fun and produce a crap result, you will not be congratulated (or re-hired), and if you have little fun and produce a great result, you'll get both.

If it's a hobby, do whatever you want.

Obviously, in terms of professional development, you want to use more forward looking tools, but what is the best measure of that - your feelings or results?

[susano]

I am a professional and I do not choose my tools based on the job.

I choose the best tools for me, invest a lot of time in getting better at them, and choose jobs I can do with minimal changes to my toolset.

To expand your analogy, if I have spent the last few years of my life getting better at driving bulldozers, I will not take any job requiring me to get into a racecar.

[laichzeit0]

> What tool will produce the best results - schedule, budget, quality, maintainability, scalabi, portability, etc.?

Old, boring, mature tools where the limitations are well understood.

[nothrabannosir]

> Are you coding as a hobby or a profession?

This isn’t mutually exclusive, surely. If anything you’d expect it to be quite closely correlated.

[turk73]

I sort of disagree with your main assertion. I do big data for a living and what I have seen is that our architecture is dictated to us from above for reasons of "fashion" not really for any reasons of practicality.

I'm actually looking for a different job for that reason.

We are required to used Java on K8s, Kafka & Cassandra for every single solution big or small because it is fashionable, not because it gets the job done well or for any other reason. I can even demonstrate how a couple of Python scripts and Pandas could do all the same work with far less overhead and achieve the same results. Crickets. Python is not sexy where I am, it is the language of peasants, apparently. Not sure what to make of it all, but that is my reality right now.

Also, I don't think you know anything at all about driving race cars. The driver has a tremendous amount of input into the car's setup because it's his life on the line out on the track. "Adapting to the situation" gets finishes, not wins.

[toss1]

Looks like we agree more than disagree. Seems like whoever is deciding on the tools, are failing to do so based on the job/project, instead opting for 'fashion' or whatever.

Good reason to seek a new situation, since you have neither appropriate tools selected for you nor input to select better ones.

Racecars? Yeah, I've only won some SCCA super-regional championships. Yes the driver does have a very large inptut into the setup, BUT it is within the constraint of the combination of the setup change and the improved driver feel must make the combination of car/driver faster. And yes, sometimes a change that makes the car technically a bit slower but gives the driver more confidence will result in faster net lap times -- and those are OK. But whatever the setup is, at the end of the test sessions, whether the car feels great or feels like crap, it's the driver's job to get the most out of it.

And I've had many situations both in the racecar and in international alpine ski racing where something felt weird/odd/unfamiliar/scary, but was fast as heck, so it was my job to adapt, rather than go back into my comfort zone.

Better to keep pushing outside your comfort zone, use tools/setups that get better results, and change your 'feel' to appreciate the better setup.