When I'm asked which modern (or in-use, or non-obsolete) programming languages I can code in, I sometimes feel like I'm playing an ego card when I say, "all of them."

Sure, I have operational experience (meaning I've written real, customer-facing projects) in C, C++, C#, Java, Go, Python, Scala, JS... and I've played around doing PoC in Rust, Dart and a few others.

More than that, though, I could pick up pretty-much any in-use language in a long weekend. So can any developer who has the years of experience in place. And then figuring out a platform for any given language is just a case of skimming the documentation so you know where to look. Nobody memorizes a whole platform any more (I think the last one I did was MFC? Maybe?).

A more accurate gauge of a developer, to me, would be to hear about their approach to design. What patterns did you use? Which did you consider and then eliminate, and why? What pivots did you make during development, and how did the final product compare to your initial vision. What got you up in the morning in terms of problems to be solved?

Once a certain threshold has been crossed, the keywords become irrelevant.

This thought process brought to you by the number of pitches I get for jobs that are based 100% on the keywords of which languages I've used in the past. These pitches pay zero attention to what I actually did. They just want to see the "[language]" or "[platform]" box checked (ticked, for you Europeans :-)).

It almost makes me want to take a week off, learn *every single modern language* in an "I've been exposed" way, and literally list them all.

Would anyone believe me?

Am I off base here? Or is this a legit position?

#programming #languages #platforms #development #experience #KaleIsNotAFood

My latest article is now up at the GoDaddy Garage. It's an overview of image optimization for web sites aimed at small business owners who are comfortable doing their own web work. Not advanced by any means.

https://garage.godaddy.com/webpro/design/best-practices-optimizing-images-websites/

Today I revisited some code I'd written about a month ago and reduced the time it takes to run a data loading job from 52 minutes down to sub-10 minutes by replacing a relatively slow API call with a direct call to local code. This is something that was "good enough" until now, but was on my radar as being eligible for improvement. Since I had a new data loading job that would take over 10 hours using the API call, I had to write the new job a better way. Copying this better code back where it could make a difference meant that all of my data loading jobs were now refactored and much faster.

The takeaway here for developers is to periodically revisit your code and refactor it. Find new efficiencies. Examine how your code has been working and consider what you might have learned since the last time you worked on it. You may notice something now that you didn't notice the last time you were in the code.

A small amount of time doing this can pay off in huge improvements.