I can't plus this enough. I hired a unicorn business minded, brilliant, can solve any software engineering or UI/UX problem engineer who happened to have a predilection for functional programming.
This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader.
I am no way suggesting that this is the intention or belief of the parent, but while I’ve got more miles on my odometer than I’d prefer, they’ve informed me that “reasonable” is better than “intelligent.”
My god how I’ve found that working with reasonable people is so much healthier, more productive and rewarding than working with the unreasonable* intelligent folks.
*I fully grant to my current and former colleagues, friends and associates that I have been irredeemably unreasonable any number of times. Consider this a small thanks :).
I suppose I’m a grey beard (in industry is 96ish) and I mean, it’s fine as a backend language in so far as dynamically (or even loosely) typed languages go. It’s just as easy (or hard) to write modular well tested code as in any number of other languages in wide use for backend services, in my XP.
> I don't have any particular answers to why string templating has been enduringly popular so far (although I can come up with theories, including that string templating is naturally reusable to other contexts, such as plain text)
My hunch is that it’s for the same reason folks love other plaintext formats: they’re readable and easily manipulated.
HTML has the added upside that it’s pretty straightforward for humans to write, which whether one likes it or not is why some folks would rather not learn some else’s DSL for generating it.
Btw, I suspect there’s a similar division in the write your own SQL vs ORM/linq world.
I appear the only one here who tells someone else (relevant) about my “brilliant” ideas from walks and showers.
It’s often my wife about a thing related to our lives, but can be something work related that I share that morning with a trusted colleague or even an email to a friend.
I think the author is describing analysis paralysis. They’re right in the sense that the most complicated work (in my XP) is often demystified with a bit of engineering over white boarding and whatifing.
A long time ago I was in a fairly desperate technical situation, that to my and my lead’s minds required a stop the world, must fix or all’s lost approach.
Product wasn’t having it, and I couldn’t negotiate my way through. In the end we ignored them for the ~4 months needed to get back to systems health. We produced a retro of our findings, before and after states, etc. and consensus, from clients and even from product leadership, was that we did the right thing.
My PM ended up quitting and I permanently broke that relationship.
The best advice I ever received was: you were right. Was it worth it?
I started doing impactful things by listening to friends express a need for something (like a shopping cart for their auto parts catalog circa 1998) and just doing it (they of course offered to pay me). I had no real clue what I was doing in code at that time, and had to learn a ton to get the job done.
Looking back on my career, taking vague requirements and turning them into something useful after a hard slog through unfamiliar territory is pretty much the common thread in all my successes.