[rb2k_]

I think the idea is not necessarily to have developers run production systems, but they still should know what production looks like and at least have basic knowledge on how to configure all of the moving parts of the system.

Having developers be 'full stack' imho reduces the amount of "works on my machine". How would a developer test the software he/she is developing on if she can't at least get close to a production environment.

Automated provisioning is just one of the usual 'devops' things that I can't imagine how a proper software engineering process would work without.

I would say that at least 20% of the people I graduated with can create software that works mostly ok when they hit the little green "run" icon in Eclipse. They were however incapable of figuring out why their jar file doesn't work in tomcat on a linux server somewhere.

Usually it was because they're using a local database with root credentials instead of a remote Database with multiple users, they have some file stashed away somewhere in their classpath, they have some binary installed in $PATH that makes the whole thing work.

I think just wanting to be a developer and not know about the stack that your application runs on is like being a painter but refusing to buy paint because you can't see what going to the store has to do with painting.

[nraynaud]

There is also an aspect that I enforced in my devop team: you built it, you will deploy it and you will keep it online and running. Don't develop something that's a pain to deploy, because you'll be the one deploying it. Don't develop something that's crazy on the database side, because you'll write the database script. As the devop, you'll have to balance the ease of development, deployment and maintenance yourself, there's no "someone else will deal with it".

That limits the crazy stuff like esoteric package function for the database, crazy port opening on the machines, esoteric daemons, or tools that can only be deployed from sources. Because the guy deciding that will be the one updating and debugging the VM creations script (for 2 different cloud provider).

But at the same times, they have access to all the tools they want, they can evaluate if something is best done on the admin or development side, they use mostly the same tools, code conventions and languages for administration and product development, and they have an immediate feedback sur how much logging to send from the application.

[Terr_]

> Having developers be 'full stack' imho reduces the amount of "works on my machine".

Not necessarily, it can also be worsened. I think Conway's Law is especially appropriate here: "[O]rganizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

When everybody shares IT responsibilities "because they can", it leads to each of those developers to run their own little customized fiefdom, with subtle (or not-so-subtle) version mismatches, mysterious lurking cronjobs, and mystery-scripts that do per-app housekeeping.

[eric_cc]

It's more like wanting to be a painter without knowing how paint brushes are created. Ideally I don't need to know how a system is configured (to an extent, of course), I just write the code.

[jsmthrowaway]

That, right there, is the attitude that leads to unmaintainable software. If you want the position of general contractor, then you'd better know how to interface with zoning authorities, draw architecture, and perform maintenance on your creation over time, or at least work very closely with the people who do know and do care about that stuff. You are not above any of those things. Ever.

All too often I see feature developers say "well, I have an operations team, I'll let them figure it out," and they (a) never leverage said operations team for advice during development, (b) don't consider operational concerns such as sharding, deployment, logging, and monitoring at all during development, (c) file a ticket against operations with three weeks to go until their deadline to perform all of those things, and (d) call for rolling operational heads when their service does not perform to their expectations (using the author's "totem pole" as their rationale). As an operations engineer, I can count way too many fucking times I've been on the other end of that from developers with attitudes like yours. It is the absolute worst part of my job.

[jvoorhis]

Or perhaps we're talking about a painter who has an irrational fear of canvases, and will only paint directly on the wall. The work takes place in production, and the results are not easily portable.

[antocv]

Jesus.

Such people exist and call themselves developers? Ah man.

[GFK_of_xmaspast]

They're everywhere, dogg.