Through the gradual process of being promoted to "senior" developer, team lead, architect, etc, I found myself in the fantasy world of senior management.

I was told, in 360 reviews, that my "management by sarcasm" approach was, while effective, making other people afraid to step out of line. The demands of the role on my work / lifestyle balance - only sleeping 5 hours a day and working pretty much every other moment - left me angry, tired and ultimately seriously ill. My kids started calling me "grumpy Dad".

I'd become everything I hated...

... so I quit.

I took a huge pay cut to go back to what I loved: coding. I refuse to be promoted to management or leadership roles. I do what I enjoy, every single day. Sure, there's things I miss. But getting back my relationships with my kids, my wife - rebuilding my health and sanity - is the greater reward.

*Chuckle*

"And can I introduce you to the chief of our QA department. Apologies for the headless bodies of software developers, that's just the way she works."

Best belly chuckle of the day!

True, but it's often not the sort of thing first and foremost in a developers mind. If she/he can connect to a database easily it's one less impediment to getting on with the task of writing code. It takes a different mindset to focus on what could possibly go wrong at a system level.

A QA once pointed this distinction out to me. As she said, "You want to make beautiful things... and I want to destroy them."

Hence the fiction of the "full stack developer". When we got rid of DBAs (developers know how to use databases yeah? why do we need people who can only do one thing really well?) we lost a lot of knowledge and culture - including the basic tenet that you simply do not expose business-critical database systems to the outside world.

Our experiences may differ here. Depending on the package manager you're using, Postgres (as an example) typically won't even allow remote access until you explicitly enable it. And usually the user associated with the base schema has at least a password. There are exceptions I realise. I guess it's part of the culture. If you've grown up with old school database systems it's almost second nature to check the security model, whereas NoSQL fans I've worked with seem to be happy that things have installed (and configuring apps to connect is simple if there's no actual password).

But I take your point. Any system needs to be hardened, and there's nothing worse than being complacent.

Wow. If that's true that's the most mindblowingly insane thing I've ever heard about Mongo. I avoid it because of a host of other issues, but if they actively screwed installs - and any of those users have support contracts with MongoDB Inc - it could well spell the end of the company. Can't find anything on the webs about it, so if you do stumble across any details I'd be interested to see them.

This is what Mongoworld looks like. A bunch of people who never understood SQL try to solve a problem they thought they had by moving to a NoSQL DB.

Mongo's security model has improved with recent releases, but the earlier approach of leaving the door wide open should never have been allowed in the first place. Compare and contrast pretty much any traditional RDBMS that is secured by default - at least minimally - because we learned our lessons the hard way years ago.

Heh. I'm showing my age. My the big takeaway tonight is just to keep my mouth shut :)

Back when I was doing AI stuff (90s), it was funnily enough using Smalltalk and Prolog - and fundamentally around natural language processing. I take your point re Lisp vs Python for AI. I doesn't feel right, the move away from symbolic models, but again... showing my age.

Yeah, you're quite correct.

I regretted that the minute I posted it. When I look back, my mentors at the time were the guys who had been using OO techniques for some time. There were an awful lot of other coders who wouldn't / couldn't follow the paradigm, and pushed back whenever you tried to talk to them about it.

Regardless, I was being just as guilty of claiming something that was patently false. I appreciate being called on it.

This seemed to be a popular myth back in the 90s. When C++ was building up steam and lot of old coders would claim that all it was did was what they'd been doing in practice, they just called it by different names.

It was complete bullshit of course. They were trying to claim prior knowledge for something fundamentally novel. I'd see them writing C++ code like a C coder and having to keep my mouth shut, because I was just a young whippersnapper with smartarse ideas. I'll admit I could never code in C like those guys did, but the world had changed... we were solving different problems than they grew up with.

I think you're right on the mark here. AI seems to be the way of the future for coding. LISP is a brilliant language for learning about core ideas in that domain - or many other domains for that matter. The analogy with Latin, and the implicit understanding of grammar and structure, is a good one.

My career started in Smalltalk in the 90s but then, thanks to a lack of job opportunities, I spent the next decade coding in Delphi, C, C++, etc. It was a shame, because I really loved coding in Smalltalk, whereas other using languages was purely to earn a living.

I've no regrets. Smalltalk gave me a grounding in OO concepts,TDD and patterns before they became de rigueur and gave me an edge when people coming from more traditional languages were struggling with the new ideas.

But honestly, everything I enjoyed in Smalltalk is available in modern languages. I've spent the better part of the last ten years earning a living coding in Ruby - and enjoying it. Going back to Smalltalk would feel retrograde.

If I were a young coder starting out today I'd be looking at languages that introduce new concepts, not stepping back in time.

Once upon a time I worked on an app that had 4 databases - MySQL, Redis, Neo4J and Influx. Each of these were to solve a specific problem (searching, time-series data, etc) even though the scale of the application (a handful of users per day) never warranted any kind of "big data" solution. And the fundamental problem remained - many of the developers didn't know how to write decent SQL.

Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases. But that's a solid, proven and ultimately boring technology. Where's the fun in that?

It's not just PHB driving the madness. Plenty of it comes from resume-driven development.

Premise: Dolphins have "human-like" intelligence and communicate through a sophisticated language.

Observation: Despite decades of human effort trying to decipher it, Dolphins have made no attempt to try to help us understand their language.

Conclusion: Dolphins don't actually want to talk to us.