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.
The value of benevolence of shopkeepers to their younger patrons cannot be understated. As a young kid I learned how PCs were put together from the local clone shop on San Pablo Ave in El Cerrito. I bought a 286 with 512k ram and two floppies and got to watch it be assembled and tested. Later (1989ish) I spent every moment I could at a Macintosh shop on Shattuck Ave in Berkeley playing SimCity on a then unheard of 20” color monitor (at least I recall it being that large). Today I’m at Google and just prior I was at Apple. The link is not direct, but the latter does not exist without the former (there was also a C64 prior to the 286, though without the shopkeeper story), at least in my case.
The author appears to be an EM at Booking.com. It seems unlikely that anyone at Booking would be working on SSD firmware or drivers, but a CDN seems like a reasonable assumption and also a useful place to plumb the depths of SSD implementations.
I’m surprised that folks are still considering metrics like LoC and commit frequency to measure developer productivity, even more so due to the (anecdotal, from my XP of 25 years in industry) fact that as developers gain in seniority they are typically spending more time with people than with code.
IMHO, developer productivity is best judged by the humans they work with.