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.
Now I have this image in my head of a female QA engineer with tentacles, with a gruesome weapon in each one. And I desperately want to make love to it.
*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."
To be fair, it's not a hard thing to check for. Just run a portscan. If you can see the database from a different box, you fucked up and need to fix it.
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."
That's the problem. People who code CANNOT be experts in ALL domains related to their jobs. From my point of view, your extremely secure code ain't worth shit if your HTML and CSS can't even validate.
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.
I may be mistaken (don't administer any Mongo databases), but as I understand it, many databases were exposed by an upgrade. Even if you had a password set the upgrade wiped it out and quietly left you exposed.
If that's what actually happened, the Mongo project has some explaining to do
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.
Your database is exposed to the internet and doesn't have a password? How is it you are still employed?
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.
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.
While Smalltalk clearly has plenty of influences in later languages, from everything I've ever heard or read, the language to learn is LISP--not Smalltalk. I've heard countless stories of people saying it retrains your brain and opens your eyes to new ways of solving problems and that "It's the best language to learn that you'll never actually use." (Because it helps in your normal life.)
It's like learning Latin in school, to help you appreciate English.
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.
I know it's not popular, so it would never make the list. But disappointed nonetheless that Whitespace didn't get scrutinised. That data would have meant something!
I watched that vid probably a dozen times, just to keep mysql smiling in the crazy days of having Neo4j, InfluxDB, Redis and Elasticsearch all thrown in by devs into the one project (no.. I shit you not...)
I used to have a simple test in interviews. "Describe the difference between an inner and an outer join". In the end I gave up. Plus management didn't want to hire the only person to answer it correctly because they were clearly too experienced.
Well, thanks to Rails and similar frameworks we've been treating the database as a dumb data repository for years. Not surprised that the kids have no idea how to make the things work properly.
The issue here really isn't SQL vs NoSQL. It's about securing the data and access. Lack of security is not inherent in NoSQL, it just occurs more often than SQL databases.
Well, I'd have to disagree here. If I install a MongoDB on some cloud VM using the default setup, I have an insecure database available on the internet. If I install Postgres, well... I can't even access the database remotely.
Much of the time NoSQL is a problem looking for a solution. I've had to deal with this a number of times before - and I'd concur what the AC above posted - the culture around NoSQL often seems to be "squeee! I have a NoSQL database.. look at my awesome speed" without investing time getting to know existing SQL properly. Or securing the systems.
Case in point: a while ago I replaced an Elasticsearch database with 40 lines of decent SQL. It wasn't rocket science (MySQL), but it was an order of magnitude faster and less complicated as it didn't require an additional server and the data pump between the SQL and Elasticsearch databases. Yes, I know Elasticsearch isn't a NoSQL db in the same sense as Mongo, but it was part of swag (4 in total) non-traditional databases in use papering over poor indexing / querying on the existing MySQL db. Oh.. and no security. That's the NoSQL culture I've experienced, and not just at one shop. All over the place.
We lost something when database administrators were given short shrift and we all became "full stack developers". So much knowledge has just gone out the window.
Slashdot Mirror
Through the gradual process of being promoted to "senior" developer, team lead, architect, etc, I found myself in the fantasy world of senior management.
... so I quit.
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...
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.
Now I have this image in my head of a female QA engineer with tentacles, with a gruesome weapon in each one. And I desperately want to make love to it.
*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."
but, but, they are noSQL databases thus, 100% injection proof... ;-)
Best belly chuckle of the day!
To be fair, it's not a hard thing to check for. Just run a portscan. If you can see the database from a different box, you fucked up and need to fix it.
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."
That's the problem. People who code CANNOT be experts in ALL domains related to their jobs. From my point of view, your extremely secure code ain't worth shit if your HTML and CSS can't even validate.
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.
I may be mistaken (don't administer any Mongo databases), but as I understand it, many databases were exposed by an upgrade. Even if you had a password set the upgrade wiped it out and quietly left you exposed.
If that's what actually happened, the Mongo project has some explaining to do
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.
Your database is exposed to the internet and doesn't have a password? How is it you are still employed?
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.
While Smalltalk clearly has plenty of influences in later languages, from everything I've ever heard or read, the language to learn is LISP--not Smalltalk. I've heard countless stories of people saying it retrains your brain and opens your eyes to new ways of solving problems and that "It's the best language to learn that you'll never actually use." (Because it helps in your normal life.)
It's like learning Latin in school, to help you appreciate English.
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.
I know it's not popular, so it would never make the list. But disappointed nonetheless that Whitespace didn't get scrutinised. That data would have meant something!
First time we hear about KDE in ages.. then we get a second story on the same day.
Konspiracy?
Russia has eleven time zones. Russia begins in Europe.
11? That's ridiculous.
So.. Perl6 is actually finished? Or is that the wrong sort of question to ask?
I remember when Basic was spelt BASIC, as in.. you know.. an acronym.
Mysql smiling. WTF? s/mysql/myself. I'm frigging tired, going to bed. Have a good night peeps.
I watched that vid probably a dozen times, just to keep mysql smiling in the crazy days of having Neo4j, InfluxDB, Redis and Elasticsearch all thrown in by devs into the one project (no.. I shit you not...)
For those without Flash, here's an another version: https://www.youtube.com/watch?...
I used to have a simple test in interviews. "Describe the difference between an inner and an outer join". In the end I gave up. Plus management didn't want to hire the only person to answer it correctly because they were clearly too experienced.
Well, thanks to Rails and similar frameworks we've been treating the database as a dumb data repository for years. Not surprised that the kids have no idea how to make the things work properly.
The issue here really isn't SQL vs NoSQL. It's about securing the data and access. Lack of security is not inherent in NoSQL, it just occurs more often than SQL databases.
Well, I'd have to disagree here. If I install a MongoDB on some cloud VM using the default setup, I have an insecure database available on the internet. If I install Postgres, well... I can't even access the database remotely.
Much of the time NoSQL is a problem looking for a solution. I've had to deal with this a number of times before - and I'd concur what the AC above posted - the culture around NoSQL often seems to be "squeee! I have a NoSQL database.. look at my awesome speed" without investing time getting to know existing SQL properly. Or securing the systems.
Case in point: a while ago I replaced an Elasticsearch database with 40 lines of decent SQL. It wasn't rocket science (MySQL), but it was an order of magnitude faster and less complicated as it didn't require an additional server and the data pump between the SQL and Elasticsearch databases. Yes, I know Elasticsearch isn't a NoSQL db in the same sense as Mongo, but it was part of swag (4 in total) non-traditional databases in use papering over poor indexing / querying on the existing MySQL db. Oh.. and no security. That's the NoSQL culture I've experienced, and not just at one shop. All over the place.
We lost something when database administrators were given short shrift and we all became "full stack developers". So much knowledge has just gone out the window.