i'm logged on and ready to go


things-to-read
@things-to-read

MongoDB’s popularity among managers during its peak was largely down to the idea that you no longer needed a database expert. Just throw the data into the document DB puddle and let your existing less-specialised developers handle it. The promise of the document database during the peak of their hype was that you didn’t need to employ as many specialists.


v21
@v21

interesting to think about how this applies on two levels:

  • if you're a small company (or a company with a small need for developers), then this kind of push towards common tools means you can get one or two generalists to handle everything
  • if you're a large company, then you're thinking about your tools through the eyes of - how can we quickly recruit enough bodies to make this stuff work

in either case you end up with the same thing this article is describing


You must log in to comment.

in reply to @things-to-read's post:

I agree with unions being the answer here. I don’t think making new or more efficient tools (that is, more useful output per input time/energy/whatever, not that all tools would meet that qualifier) is bad inherently, but it can absolutely be used as a leverage against labor, and it needs to be balanced with labor protections, similar to how the film industry went through labor negotiations to keep humans involved in production and define the ways automated tools are allowed to be used.

in reply to @v21's post:

I feel like this article is over-complicating things a bit.

It's certainly plausible, but everytime I've witnessed a similar situation they've skipped over the "slightly more generic and exploitable technology" step and gone straight to buying "off the shelf" snake oil with the intention of eliminating all development staff.

Pinned Tags